aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-05-13 15:40:16 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2013-05-13 15:40:16 -0400
commite9c336c78638c191642b18628c306d1c1573fb12 (patch)
treea827caa567b7d1652a5ee65244ec5c88cc9847dd /src
parent904af8db8a99409257db1eed0b056c8098e9013c (diff)
downloadpostgresql-e9c336c78638c191642b18628c306d1c1573fb12.tar.gz
postgresql-e9c336c78638c191642b18628c306d1c1573fb12.zip
Fix handling of OID wraparound while in standalone mode.
If OID wraparound should occur while in standalone mode (unlikely but possible), we want to advance the counter to FirstNormalObjectId not FirstBootstrapObjectId. Otherwise, user objects might be created with OIDs in the system-reserved range. That isn't immediately harmful but it poses a risk of conflicts during future pg_upgrade operations. Noted by Andres Freund. Back-patch to all supported branches, since all of them are supported sources for pg_upgrade operations.
Diffstat (limited to 'src')
-rw-r--r--src/backend/access/transam/varsup.c18
1 files changed, 9 insertions, 9 deletions
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 64537d01280..0579c84bea2 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -451,18 +451,18 @@ GetNewObjectId(void)
* iterations in GetNewOid.) Note we are relying on unsigned comparison.
*
* During initdb, we start the OID generator at FirstBootstrapObjectId, so
- * we only enforce wrapping to that point when in bootstrap or standalone
- * mode. The first time through this routine after normal postmaster
- * start, the counter will be forced up to FirstNormalObjectId. This
- * mechanism leaves the OIDs between FirstBootstrapObjectId and
- * FirstNormalObjectId available for automatic assignment during initdb,
- * while ensuring they will never conflict with user-assigned OIDs.
+ * we only wrap if before that point when in bootstrap or standalone mode.
+ * The first time through this routine after normal postmaster start, the
+ * counter will be forced up to FirstNormalObjectId. This mechanism
+ * leaves the OIDs between FirstBootstrapObjectId and FirstNormalObjectId
+ * available for automatic assignment during initdb, while ensuring they
+ * will never conflict with user-assigned OIDs.
*/
if (ShmemVariableCache->nextOid < ((Oid) FirstNormalObjectId))
{
if (IsPostmasterEnvironment)
{
- /* wraparound in normal environment */
+ /* wraparound, or first post-initdb assignment, in normal mode */
ShmemVariableCache->nextOid = FirstNormalObjectId;
ShmemVariableCache->oidCount = 0;
}
@@ -471,8 +471,8 @@ GetNewObjectId(void)
/* we may be bootstrapping, so don't enforce the full range */
if (ShmemVariableCache->nextOid < ((Oid) FirstBootstrapObjectId))
{
- /* wraparound in standalone environment? */
- ShmemVariableCache->nextOid = FirstBootstrapObjectId;
+ /* wraparound in standalone mode (unlikely but possible) */
+ ShmemVariableCache->nextOid = FirstNormalObjectId;
ShmemVariableCache->oidCount = 0;
}
}