Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 852a5cd

Browse files
committed
Avoid problems with OID wraparound during WAL replay.
Fix a longstanding thinko in replay of NEXTOID and checkpoint records: we tried to advance nextOid only if it was behind the value in the WAL record, but the comparison would draw the wrong conclusion if OID wraparound had occurred since the previous value. Better to just unconditionally assign the new value, since OID assignment shouldn't be happening during replay anyway. The consequences of a failure to update nextOid would be pretty minimal, since we have long had the code set up to obtain another OID and try again if the generated value is already in use. But in the worst case there could be significant performance glitches while such loops iterate through many already-used OIDs before finding a free one. The odds of a wraparound happening during WAL replay would be small in a crash-recovery scenario, and the length of any ensuing OID-assignment stall quite limited anyway. But neither of these statements hold true for a replication slave that follows a WAL stream for a long period; its behavior upon going live could be almost unboundedly bad. Hence it seems worth back-patching this fix into all supported branches. Already fixed in HEAD in commit c6d76d7.
1 parent 94c5aa6 commit 852a5cd

File tree

1 file changed

+12
-11
lines changed
  • src/backend/access/transam

1 file changed

+12
-11
lines changed

src/backend/access/transam/xlog.c

Lines changed: 12 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -7939,12 +7939,15 @@ xlog_redo(XLogRecPtr lsn, XLogRecord *record)
79397939
{
79407940
Oid nextOid;
79417941

7942+
/*
7943+
* We used to try to take the maximum of ShmemVariableCache->nextOid
7944+
* and the recorded nextOid, but that fails if the OID counter wraps
7945+
* around. Since no OID allocation should be happening during replay
7946+
* anyway, better to just believe the record exactly.
7947+
*/
79427948
memcpy(&nextOid, XLogRecGetData(record), sizeof(Oid));
7943-
if (ShmemVariableCache->nextOid < nextOid)
7944-
{
7945-
ShmemVariableCache->nextOid = nextOid;
7946-
ShmemVariableCache->oidCount = 0;
7947-
}
7949+
ShmemVariableCache->nextOid = nextOid;
7950+
ShmemVariableCache->oidCount = 0;
79487951
}
79497952
else if (info == XLOG_CHECKPOINT_SHUTDOWN)
79507953
{
@@ -8032,15 +8035,13 @@ xlog_redo(XLogRecPtr lsn, XLogRecord *record)
80328035
CheckPoint checkPoint;
80338036

80348037
memcpy(&checkPoint, XLogRecGetData(record), sizeof(CheckPoint));
8035-
/* In an ONLINE checkpoint, treat the counters like NEXTOID */
8038+
/* In an ONLINE checkpoint, treat the XID counter as a minimum */
80368039
if (TransactionIdPrecedes(ShmemVariableCache->nextXid,
80378040
checkPoint.nextXid))
80388041
ShmemVariableCache->nextXid = checkPoint.nextXid;
8039-
if (ShmemVariableCache->nextOid < checkPoint.nextOid)
8040-
{
8041-
ShmemVariableCache->nextOid = checkPoint.nextOid;
8042-
ShmemVariableCache->oidCount = 0;
8043-
}
8042+
/* ... but still treat OID counter as exact */
8043+
ShmemVariableCache->nextOid = checkPoint.nextOid;
8044+
ShmemVariableCache->oidCount = 0;
80448045
MultiXactAdvanceNextMXact(checkPoint.nextMulti,
80458046
checkPoint.nextMultiOffset);
80468047
if (TransactionIdPrecedes(ShmemVariableCache->oldestXid,

0 commit comments

Comments
 (0)