Обсуждение: Single-User Mode oid assignment

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—16383is free for OIDs assigned automatically by genbki.pl or during initdb. 

Is such difference in oid assignment in Single-User Mode expected?

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—16383is 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