diff options
| -rw-r--r-- | doc/src/sgml/bki.sgml | 20 | ||||
| -rw-r--r-- | src/backend/catalog/genbki.pl | 10 | ||||
| -rw-r--r-- | src/include/access/transam.h | 19 |
3 files changed, 33 insertions, 16 deletions
diff --git a/doc/src/sgml/bki.sgml b/doc/src/sgml/bki.sgml index 0dd753bc6f5..aa3d6f8e593 100644 --- a/doc/src/sgml/bki.sgml +++ b/doc/src/sgml/bki.sgml @@ -422,19 +422,21 @@ </para> <para> - The OID counter starts at 10000 at the beginning of a bootstrap run. - If a row from a source other than <filename>postgres.bki</filename> - is inserted into a table that requires OIDs, then it will receive an - OID of 10000 or above. For example, objects created while running - the <filename>information_schema.sql</filename> script receive such - OIDs. + If <filename>genbki.pl</filename> needs to assign an OID to a catalog + entry that does not have a manually-assigned OID, it will use a value in + the range 10000—11999. The server's OID counter is set to 12000 + at the start of a bootstrap run. Thus objects created by regular SQL + commands during the later phases of bootstrap, such as objects created + while running the <filename>information_schema.sql</filename> script, + receive OIDs of 12000 or above. </para> <para> OIDs assigned during normal database operation are constrained to be - 16384 or higher. This leaves the range 10000—16383 available - for OIDs assigned automatically during bootstrap. These OIDs are not - considered stable, and may change from one installation to another. + 16384 or higher. This ensures that the range 10000—16383 is free + for OIDs assigned automatically by <filename>genbki.pl</filename> or + during bootstrap. These automatically-assigned OIDs are not considered + stable, and may change from one installation to another. </para> </sect2> diff --git a/src/backend/catalog/genbki.pl b/src/backend/catalog/genbki.pl index cdda2c29e45..5eaa7dea776 100644 --- a/src/backend/catalog/genbki.pl +++ b/src/backend/catalog/genbki.pl @@ -138,10 +138,13 @@ die "found $found duplicate OID(s) in catalog data\n" if $found; # Oids not specified in the input files are automatically assigned, -# starting at FirstGenbkiObjectId. +# starting at FirstGenbkiObjectId, extending up to FirstBootstrapObjectId. my $FirstGenbkiObjectId = Catalog::FindDefinedSymbol('access/transam.h', $include_path, 'FirstGenbkiObjectId'); +my $FirstBootstrapObjectId = + Catalog::FindDefinedSymbol('access/transam.h', $include_path, + 'FirstBootstrapObjectId'); my $GenbkiNextOid = $FirstGenbkiObjectId; @@ -625,6 +628,11 @@ foreach my $declaration (@index_decls) # last command in the BKI file: build the indexes declared above print $bki "build indices\n"; +# check that we didn't overrun available OIDs +die + "genbki OID counter reached $GenbkiNextOid, overrunning FirstBootstrapObjectId\n" + if $GenbkiNextOid > $FirstBootstrapObjectId; + # Now generate schemapg.h diff --git a/src/include/access/transam.h b/src/include/access/transam.h index 444be4aeb52..78997e533e7 100644 --- a/src/include/access/transam.h +++ b/src/include/access/transam.h @@ -72,10 +72,13 @@ * Object ID (OID) zero is InvalidOid. * * OIDs 1-9999 are reserved for manual assignment (see .dat files in - * src/include/catalog/), with 9000-9999 tentatively reserved for forks. + * src/include/catalog/). Of these, 8000-9999 are reserved for + * development purposes (such as in-progress patches and forks); + * they should not appear in released versions. * - * OIDs 10000-11999 are reserved for assignment by genbki.pl, when the - * .dat files in src/include/catalog/ do not specify oids. + * OIDs 10000-11999 are reserved for assignment by genbki.pl, for use + * when the .dat files in src/include/catalog/ do not specify an OID + * for a catalog entry that requires one. * * OIDS 12000-16383 are reserved for assignment during initdb * using the OID generator. (We start the generator at 12000.) @@ -84,9 +87,13 @@ * during normal multiuser operation. (We force the generator up to * 16384 as soon as we are in normal operation.) * - * The choices of 10000, 12000 and 16384 are completely arbitrary, and can be - * moved if we run low on OIDs in either category. Changing the macros below - * should be sufficient to do this. + * The choices of 8000, 10000 and 12000 are completely arbitrary, and can be + * moved if we run low on OIDs in any category. Changing the macros below, + * and updating relevant documentation (see bki.sgml and RELEASE_CHANGES), + * should be sufficient to do this. Moving the 16384 boundary between + * initdb-assigned OIDs and user-defined objects would be substantially + * more painful, however, since some user-defined OIDs will appear in + * on-disk data; such a change would probably break pg_upgrade. * * NOTE: if the OID generator wraps around, we skip over OIDs 0-16383 * and resume with 16384. This minimizes the odds of OID conflict, by not |