Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commite9c336c

Browse files
committed
Fix handling of OID wraparound while in standalone mode.
If OID wraparound should occur while in standalone mode (unlikely butpossible), we want to advance the counter to FirstNormalObjectId notFirstBootstrapObjectId. Otherwise, user objects might be created with OIDsin the system-reserved range. That isn't immediately harmful but it posesa risk of conflicts during future pg_upgrade operations.Noted by Andres Freund. Back-patch to all supported branches, since all ofthem are supported sources for pg_upgrade operations.
1 parent904af8d commite9c336c

File tree

1 file changed

+9
-9
lines changed

1 file changed

+9
-9
lines changed

‎src/backend/access/transam/varsup.c

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -451,18 +451,18 @@ GetNewObjectId(void)
451451
* iterations in GetNewOid.) Note we are relying on unsigned comparison.
452452
*
453453
* During initdb, we start the OID generator at FirstBootstrapObjectId, so
454-
* we onlyenforce wrapping to that point when in bootstrap or standalone
455-
*mode.The first time through this routine after normal postmaster
456-
*start, thecounter will be forced up to FirstNormalObjectId. This
457-
*mechanismleaves the OIDs between FirstBootstrapObjectId and
458-
*FirstNormalObjectIdavailable for automatic assignment during initdb,
459-
*while ensuring theywill never conflict with user-assigned OIDs.
454+
* we onlywrap if before that point when in bootstrap or standalone mode.
455+
* The first time through this routine after normal postmaster start, the
456+
* counter will be forced up to FirstNormalObjectId.This mechanism
457+
* leaves the OIDs between FirstBootstrapObjectId and FirstNormalObjectId
458+
* available for automatic assignment during initdb, while ensuring they
459+
* will never conflict with user-assigned OIDs.
460460
*/
461461
if (ShmemVariableCache->nextOid< ((Oid)FirstNormalObjectId))
462462
{
463463
if (IsPostmasterEnvironment)
464464
{
465-
/* wraparoundin normalenvironment */
465+
/* wraparound, or first post-initdb assignment,in normalmode */
466466
ShmemVariableCache->nextOid=FirstNormalObjectId;
467467
ShmemVariableCache->oidCount=0;
468468
}
@@ -471,8 +471,8 @@ GetNewObjectId(void)
471471
/* we may be bootstrapping, so don't enforce the full range */
472472
if (ShmemVariableCache->nextOid< ((Oid)FirstBootstrapObjectId))
473473
{
474-
/* wraparound in standaloneenvironment? */
475-
ShmemVariableCache->nextOid=FirstBootstrapObjectId;
474+
/* wraparound in standalonemode (unlikely but possible) */
475+
ShmemVariableCache->nextOid=FirstNormalObjectId;
476476
ShmemVariableCache->oidCount=0;
477477
}
478478
}

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp