aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-12-02 15:20:03 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2012-12-02 15:20:03 -0500
commitaaceb0d6acce900144c147fca3d682c11c6adf0c (patch)
tree9f5b00adabe11e03cec00a6d82a30e67bcaf2662
parentc3f64adef829ea41d3761822b8a043aec3d651f2 (diff)
downloadpostgresql-aaceb0d6acce900144c147fca3d682c11c6adf0c.tar.gz
postgresql-aaceb0d6acce900144c147fca3d682c11c6adf0c.zip
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.
-rw-r--r--src/backend/access/transam/xlog.c11
-rw-r--r--src/backend/storage/ipc/standby.c4
-rw-r--r--src/include/storage/standby.h2
3 files changed, 3 insertions, 14 deletions
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 5a06ae2a4a3..50e2b22dd70 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -8019,18 +8019,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 0658feb076c..8b3b8331aa9 100644
--- 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 ed3b66b35df..4b69be077b1 100644
--- a/src/include/storage/standby.h
+++ b/src/include/storage/standby.h
@@ -110,6 +110,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 */