On Sat, 2024-03-16 at 14:14 +0300, PetSerAl wrote:
> I have following script, which initialize two clusters:
>
> echo CREATE ROLE new_user WITH LOGIN;>init_cluster.sql
> echo CREATE DATABASE new_database WITH OWNER = new_user;>>init_cluster.sql
> initdb -D case1 -U postgres
> pg_ctl start -D case1 -w
> psql "host=localhost dbname=postgres user=postgres"<init_cluster.sql
> pg_ctl stop -D case1 -m smart -w
> initdb -D case2 -U postgres
> postgres --single -D case2 postgres<init_cluster.sql
>
> In case1 I have following oid assigned:
> new_user: 16384
> new_database: 16385
>
> In case2:
> new_user: 15062
> new_database: 15063
> And pgAdmin does not show new_database in the server tree.
> Documentation says following:
> > OIDs assigned during normal database operation are constrained to be 16384 or higher. This ensures that the range 10000—16383 is free for OIDs assigned automatically by genbki.pl or during initdb.
>
> Is such difference in oid assignment in Single-User Mode expected?
Yes; see the comment in GetNewObjectId():
/*
* Check for wraparound of the OID counter. We *must* not return 0
* (InvalidOid), and in normal operation we mustn't return anything below
* FirstNormalObjectId since that range is reserved for initdb (see
* IsCatalogRelationOid()). Note we are relying on unsigned comparison.
*
* During initdb, we start the OID generator at FirstGenbkiObjectId, so 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 FirstGenbkiObjectId and FirstNormalObjectId
* available for automatic assignment during initdb, while ensuring they
* will never conflict with user-assigned OIDs.
*/16384
Object IDs are forced to be 16384 or above "after normal postmaster start".
Yours,
Laurenz Albe
