rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
36,942 Commits 36 Branches 606 Tags 423 MiB
C 86%
PLpgSQL 5.5%
Perl 4.1%
Yacc 1.3%
Makefile 0.7%
Other 2.3%
Go to file
Tom Lane 78db307bb2 Defend against bad relfrozenxid/relminmxid/datfrozenxid/datminmxid values. 
In commit a61daa14d5, we fixed pg_upgrade so
that it would install sane relminmxid and datminmxid values, but that does
not cure the problem for installations that were already pg_upgraded to
9.3; they'll initially have "1" in those fields.  This is not a big problem
so long as 1 is "in the past" compared to the current nextMultiXact
counter.  But if an installation were more than halfway to the MXID wrap
point at the time of upgrade, 1 would appear to be "in the future" and
that would effectively disable tracking of oldest MXIDs in those
tables/databases, until such time as the counter wrapped around.

While in itself this isn't worse than the situation pre-9.3, where we did
not manage MXID wraparound risk at all, the consequences of premature
truncation of pg_multixact are worse now; so we ought to make some effort
to cope with this.  We discussed advising users to fix the tracking values
manually, but that seems both very tedious and very error-prone.

Instead, this patch adopts two amelioration rules.  First, a relminmxid
value that is "in the future" is allowed to be overwritten with a
full-table VACUUM's actual freeze cutoff, ignoring the normal rule that
relminmxid should never go backwards.  (This essentially assumes that we
have enough defenses in place that wraparound can never occur anymore,
and thus that a value "in the future" must be corrupt.)  Second, if we see
any "in the future" values then we refrain from truncating pg_clog and
pg_multixact.  This prevents loss of clog data until we have cleaned up
all the broken tracking data.  In the worst case that could result in
considerable clog bloat, but in practice we expect that relfrozenxid-driven
freezing will happen soon enough to fix the problem before clog bloat
becomes intolerable.  (Users could do manual VACUUM FREEZEs if not.)

Note that this mechanism cannot save us if there are already-wrapped or
already-truncated-away MXIDs in the table; it's only capable of dealing
with corrupt tracking values.  But that's the situation we have with the
pg_upgrade bug.

For consistency, apply the same rules to relfrozenxid/datfrozenxid.  There
are not known mechanisms for these to get messed up, but if they were, the
same tactics seem appropriate for fixing them.
 		2014-07-21 11:41:53 -04:00
config Remove some useless code in the configure script. 2014-07-01 17:51:53 -04:00
contrib pg_upgrade: Fix spacing in help output 2014-07-15 15:08:16 -04:00
doc Replace "internationalize" with "localize" where appropriate 2014-07-20 21:39:37 -04:00
src Defend against bad relfrozenxid/relminmxid/datfrozenxid/datminmxid values. 2014-07-21 11:41:53 -04:00
.dir-locals.el Update Emacs configuration 2013-08-13 20:08:44 -04:00
.gitattributes gitattributes: Make syntax compatible with older Git versions 2013-11-12 21:58:46 -05:00
.gitignore Add *.pot to .gitignore 2013-10-19 10:56:52 -04:00
COPYRIGHT Update copyright for 2014 2014-01-07 16:05:30 -05:00
GNUmakefile.in Add TAP tests for client programs 2014-04-14 21:33:46 -04:00
HISTORY Improve text of stub HISTORY file. 2014-02-12 18:16:17 -05:00
Makefile Allow make check in PL directories 2011-02-15 06:52:12 +02:00
README Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:04 -05:00
README.git Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:04 -05:00
aclocal.m4 Remove cvs keywords from all files. 2010-09-20 22:08:53 +02:00
configure Move check for SSL_get_current_compression to run on mingw 2014-07-15 22:02:46 +02:00
configure.in Move check for SSL_get_current_compression to run on mingw 2014-07-15 22:02:46 +02:00

README 

PostgreSQL Database Management System
=====================================

This directory contains the source code distribution of the PostgreSQL
database management system.

PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions, foreign keys, subqueries, triggers, user-defined types
and functions.  This distribution also contains C language bindings.

PostgreSQL has many language interfaces, many of which are listed here:

	http://www.postgresql.org/download

See the file INSTALL for instructions on how to build and install
PostgreSQL.  That file also lists supported operating systems and
hardware platforms and contains information regarding any other
software packages that are required to build or run the PostgreSQL
system.  Copyright and license information can be found in the
file COPYRIGHT.  A comprehensive documentation set is included in this
distribution; it can be read as described in the installation
instructions.

The latest version of this software may be obtained at
http://www.postgresql.org/download/.  For more information look at our
web site located at http://www.postgresql.org/.