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

Commite150773

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 parentdbd68df commite150773

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
@@ -449,18 +449,18 @@ GetNewObjectId(void)
449449
* iterations in GetNewOid.) Note we are relying on unsigned comparison.
450450
*
451451
* During initdb, we start the OID generator at FirstBootstrapObjectId, so
452-
* we onlyenforce wrapping to that point when in bootstrap or standalone
453-
*mode.The first time through this routine after normal postmaster
454-
*start, thecounter will be forced up to FirstNormalObjectId. This
455-
*mechanismleaves the OIDs between FirstBootstrapObjectId and
456-
*FirstNormalObjectIdavailable for automatic assignment during initdb,
457-
*while ensuring theywill never conflict with user-assigned OIDs.
452+
* we onlywrap if before that point when in bootstrap or standalone mode.
453+
* The first time through this routine after normal postmaster start, the
454+
* counter will be forced up to FirstNormalObjectId.This mechanism
455+
* leaves the OIDs between FirstBootstrapObjectId and FirstNormalObjectId
456+
* available for automatic assignment during initdb, while ensuring they
457+
* will never conflict with user-assigned OIDs.
458458
*/
459459
if (ShmemVariableCache->nextOid< ((Oid)FirstNormalObjectId))
460460
{
461461
if (IsPostmasterEnvironment)
462462
{
463-
/* wraparoundin normalenvironment */
463+
/* wraparound, or first post-initdb assignment,in normalmode */
464464
ShmemVariableCache->nextOid=FirstNormalObjectId;
465465
ShmemVariableCache->oidCount=0;
466466
}
@@ -469,8 +469,8 @@ GetNewObjectId(void)
469469
/* we may be bootstrapping, so don't enforce the full range */
470470
if (ShmemVariableCache->nextOid< ((Oid)FirstBootstrapObjectId))
471471
{
472-
/* wraparound in standaloneenvironment? */
473-
ShmemVariableCache->nextOid=FirstBootstrapObjectId;
472+
/* wraparound in standalonemode (unlikely but possible) */
473+
ShmemVariableCache->nextOid=FirstNormalObjectId;
474474
ShmemVariableCache->oidCount=0;
475475
}
476476
}

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp