aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/transam/xlog.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-04-11 18:11:29 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-04-11 18:11:29 -0400
commitd1e9079295e9e6fcab8f2ad9c69dd1be8e876d47 (patch)
tree537cf49a55082e8615c11ee2736d492257305af5 /src/backend/access/transam/xlog.c
parent0408e1ed599b06d9bca2927a50a4be52c9e74bb9 (diff)
downloadpostgresql-d1e9079295e9e6fcab8f2ad9c69dd1be8e876d47.tar.gz
postgresql-d1e9079295e9e6fcab8f2ad9c69dd1be8e876d47.zip
Ignore nextOid when replaying an ONLINE checkpoint.
The nextOid value is from the start of the checkpoint and may well be stale compared to values from more recent XLOG_NEXTOID records. Previously, we adopted it anyway, allowing the OID counter to go backwards during a crash. While this should be harmless, it contributed to the severity of the bug fixed in commit 0408e1ed5, by allowing duplicate TOAST OIDs to be assigned immediately following a crash. Without this error, that issue would only have arisen when TOAST objects just younger than a multiple of 2^32 OIDs were deleted and then not vacuumed in time to avoid a conflict. Pavan Deolasee Discussion: https://postgr.es/m/CABOikdOgWT2hHkYG3Wwo2cyZJq2zfs1FH0FgX-=h4OLosXHf9w@mail.gmail.com
Diffstat (limited to 'src/backend/access/transam/xlog.c')
-rw-r--r--src/backend/access/transam/xlog.c19
1 files changed, 14 insertions, 5 deletions
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index a51df6b0b90..08dc9ba031b 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -9785,11 +9785,20 @@ xlog_redo(XLogReaderState *record)
checkPoint.nextXid))
ShmemVariableCache->nextXid = checkPoint.nextXid;
LWLockRelease(XidGenLock);
- /* ... but still treat OID counter as exact */
- LWLockAcquire(OidGenLock, LW_EXCLUSIVE);
- ShmemVariableCache->nextOid = checkPoint.nextOid;
- ShmemVariableCache->oidCount = 0;
- LWLockRelease(OidGenLock);
+
+ /*
+ * We ignore the nextOid counter in an ONLINE checkpoint, preferring
+ * to track OID assignment through XLOG_NEXTOID records. The nextOid
+ * counter is from the start of the checkpoint and might well be stale
+ * compared to later XLOG_NEXTOID records. We could try to take the
+ * maximum of the nextOid counter and our latest value, but since
+ * there's no particular guarantee about the speed with which the OID
+ * counter wraps around, that's a risky thing to do. In any case,
+ * users of the nextOid counter are required to avoid assignment of
+ * duplicates, so that a somewhat out-of-date value should be safe.
+ */
+
+ /* Handle multixact */
MultiXactAdvanceNextMXact(checkPoint.nextMulti,
checkPoint.nextMultiOffset);