Don't advance checkPoint.nextXid near the end of a checkpoint sequence.

This reverts commit c11130690d6dca64267201a169cfb38c1adec5ef 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.

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 4d9721bae8f5a4d634e1cb3c7ac4630239e425de..9d54ab76469c5f8055c9009e9d6453e59920abee 100644 (file)
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7848,18 +7848,9 @@ CreateCheckPoint(int flags)
         *
         * If we are shutting down, or Startup process is completing crash
         * recovery we don't need to write running xact data.
-        *
-        * Update checkPoint.nextXid since we may have a later value. If we
-        * do update the value, and we have wrapped, increment epoch also.
         */
        if (!shutdown && XLogStandbyInfoActive())
-       {
-               TransactionId prevXid = checkPoint.nextXid;
-
-               LogStandbySnapshot(&checkPoint.nextXid);
-               if (checkPoint.nextXid < prevXid)
-                       checkPoint.nextXidEpoch++;
-       }
+               LogStandbySnapshot();
 
        START_CRIT_SECTION();
 

diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index e1a9fbb7262ed7d1dcb2a13c65a85d16b2b9fb3a..81f94b7155f957e90f4ada2a036700e93811bead 100644 (file)
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -865,7 +865,7 @@ standby_desc(StringInfo buf, uint8 xl_info, char *rec)
  * from a time when they were possible.
  */
 void
-LogStandbySnapshot(TransactionId *nextXid)
+LogStandbySnapshot(void)
 {
        RunningTransactions running;
        xl_standby_lock *locks;
@@ -894,8 +894,6 @@ LogStandbySnapshot(TransactionId *nextXid)
        LogCurrentRunningXacts(running);
        /* GetRunningTransactionData() acquired XidGenLock, we must release it */
        LWLockRelease(XidGenLock);
-
-       *nextXid = running->nextXid;
 }
 
 /*

diff --git a/src/include/storage/standby.h b/src/include/storage/standby.h
index 787fc01d3eab951f9e457c6bcf17eb5ca9fdb0fb..fa36e6b5fc350695dc93c4ecd2009d6b86373ca4 100644 (file)
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -111,6 +111,6 @@ typedef RunningTransactionsData *RunningTransactions;
 extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
 extern void LogAccessExclusiveLockPrepare(void);
 
-extern void LogStandbySnapshot(TransactionId *nextXid);
+extern void LogStandbySnapshot(void);
 
 #endif   /* STANDBY_H */