mirror of
https://github.com/postgres/postgres.git
synced 2025-10-22 14:32:25 +03:00
Reduce the range of OIDs reserved for genbki.pl.
Commit ab596105b
increased FirstBootstrapObjectId from 12000 to 13000,
but we've had some push-back about that. It's worrisome to reduce the
daylight between there and FirstNormalObjectId, because the number of
OIDs consumed during initdb for collation objects is hard to predict.
We can improve the situation by abandoning the assumption that these
OIDs must be globally unique. It should be sufficient for them to be
unique per-catalog. (Any code that's unhappy about that is broken
anyway, since no more than per-catalog uniqueness can be guaranteed
once the OID counter wraps around.) With that change, the largest OID
assigned during genbki.pl (starting from a base of 10000) is a bit
under 11000. This allows reverting FirstBootstrapObjectId to 12000
with reasonable confidence that that will be sufficient for many years
to come.
We are not, at this time, abandoning the expectation that
hand-assigned OIDs (below 10000) are globally unique. Someday that'll
likely be necessary, but the need seems years away still.
This is late for v14, but it seems worth doing it now so that
downstream software doesn't have to deal with the consequences of
a change in FirstBootstrapObjectId. In any case, we already
bought into forcing an initdb for beta2, so another catversion
bump won't hurt.
Discussion: https://postgr.es/m/1665197.1622065382@sss.pgh.pa.us
This commit is contained in:
@@ -161,18 +161,20 @@ FullTransactionIdAdvance(FullTransactionId *dest)
|
||||
* development purposes (such as in-progress patches and forks);
|
||||
* they should not appear in released versions.
|
||||
*
|
||||
* OIDs 10000-12999 are reserved for assignment by genbki.pl, for use
|
||||
* 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.
|
||||
* for a catalog entry that requires one. Note that genbki.pl assigns
|
||||
* these OIDs independently in each catalog, so they're not guaranteed
|
||||
* to be globally unique.
|
||||
*
|
||||
* OIDS 13000-16383 are reserved for assignment during initdb
|
||||
* using the OID generator. (We start the generator at 13000.)
|
||||
* OIDS 12000-16383 are reserved for assignment during initdb
|
||||
* using the OID generator. (We start the generator at 12000.)
|
||||
*
|
||||
* OIDs beginning at 16384 are assigned from the OID generator
|
||||
* during normal multiuser operation. (We force the generator up to
|
||||
* 16384 as soon as we are in normal operation.)
|
||||
*
|
||||
* The choices of 8000, 10000 and 13000 are completely arbitrary, and can be
|
||||
* 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
|
||||
@@ -186,7 +188,7 @@ FullTransactionIdAdvance(FullTransactionId *dest)
|
||||
* ----------
|
||||
*/
|
||||
#define FirstGenbkiObjectId 10000
|
||||
#define FirstBootstrapObjectId 13000
|
||||
#define FirstBootstrapObjectId 12000
|
||||
#define FirstNormalObjectId 16384
|
||||
|
||||
/*
|
||||
|
Reference in New Issue
Block a user