8000 Don't advance checkPoint.nextXid near the end of a checkpoint sequence. · danielcode/postgres@aaceb0d · GitHub
[go: up one dir, main page]

Skip to content

Commit aaceb0d

Browse files
committed
Don't advance checkPoint.nextXid near the end of a checkpoint sequence.
This reverts commit c111306 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.
1 parent c3f64ad commit aaceb0d

File tree

3 files changed

+3
-14
lines changed

3 files changed

+3
-14
lines changed

src/backend/access/transam/xlog.c

Lines changed: 1 addition & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -8019,18 +8019,9 @@ CreateCheckPoint(int flags)
80198019
*
80208020
* If we are shutting down, or Startup process is completing crash
80218021
* recovery we don't need to write running xact data.
8022-
*
8023-
* Update checkPoint.nextXid since we may have a later value. If we
8024-
* do update the value, and we have wrapped, increment epoch also.
80258022
*/
80268023
if (!shutdown && XLogStandbyInfoActive())
8027-
{
8028-
TransactionId prevXid = checkPoint.nextXid;
8029-
8030-
LogStandbySnapshot(&checkPoint.nextXid);
8031-
if (checkPoint.nextXid < prevXid)
8032-
checkPoint.nextXidEpoch++;
8033-
}
8024+
LogStandbySnapshot();
80348025

80358026
START_CRIT_SECTION();
80368027

src/backend/storage/ipc/standby.c

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -865,7 +865,7 @@ standby_desc(StringInfo buf, uint8 xl_info, char *rec)
865865
* from a time when they were possible.
866866
*/
867867
void
868-
LogStandbySnapshot(TransactionId *nextXid)
868+
LogStandbySnapshot(void)
869869
{
870870
RunningTransactions running;
871871
xl_standby_lock *locks;
@@ -894,8 +894,6 @@ LogStandbySnapshot(TransactionId *nextXid)
894894
LogCurrentRunningXacts(running);
895895
/* GetRunningTransactionData() acquired XidGenLock, we must release it */
896896
LWLockRelease(XidGenLock);
897-
898-
*nextXid = running->nextXid;
899897
}
900898

901899
/*

src/include/storage/standby.h

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -110,6 +110,6 @@ typedef RunningTransactionsData *RunningTransactions;
110110
extern void LogAccessExclusiveLock(Oid dbOid, Oid relOid);
111111
extern void LogAccessExclusiveLockPrepare(void);
112112

113-
extern void LogStandbySnapshot(TransactionId *nextXid);
113+
extern void LogStandbySnapshot(void);
114114

115115
#endif /* STANDBY_H */

0 commit comments

Comments
 (0)
0