Tom Lane d08fd1f849 Don't advance checkPoint.nextXid near the end of a checkpoint sequence. ... This reverts commit c11130690d in favor of actually fixing the problem: namely, that we should never have been modifying the checkpoint record's nextXid at this point to begin with. The nextXid should match the state as of the checkpoint's logical WAL position (ie the redo point), not the state as of its physical position. It's especially bogus to advance it in some wal_levels and not others. In any case there is no need for the checkpoint record to carry the same nextXid shown in the XLOG_RUNNING_XACTS record just emitted by LogStandbySnapshot, as any replay operation will already have adopted that value as current. This fixes bug #7710 from Tarvi Pillessaar, and probably also explains bug #6291 from Daniel Farina, in that if a checkpoint were in progress at the instant of XID wraparound, the epoch bump would be lost as reported. (And, of course, these days there's at least a 50-50 chance of a checkpoint being in progress at any given instant.) Diagnosed by me and independently by Andres Freund. Back-patch to all branches supporting hot standby.		2012-12-02 15:20:08 -05:00
..
common	Make a code-cleanup pass over the collations patch.	2011-04-22 17:43:18 -04:00
gin	Fix multiple problems in WAL replay.	2012-11-12 22:05:21 -05:00
gist	Fix multiple problems in WAL replay.	2012-11-12 22:05:21 -05:00
hash	Hash indexes had better pass the index collation to support functions, too.	2011-04-23 14:13:09 -04:00
heap	Fix assorted bugs in CREATE INDEX CONCURRENTLY.	2012-11-29 14:51:46 -05:00
index	Prevent synchronized scanning when systable_beginscan chooses a heapscan.	2012-05-26 19:09:59 -04:00
nbtree	Fix multiple problems in WAL replay.	2012-11-12 22:05:21 -05:00
transam	Don't advance checkPoint.nextXid near the end of a checkpoint sequence.	2012-12-02 15:20:08 -05:00
Makefile	Remove cvs keywords from all files.	2010-09-20 22:08:53 +02:00