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
<para>
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—12999. The server's OID counter is set to 13000
+ 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 13000 or above.
+ receive OIDs of 12000 or above.
</para>
<para>
die "found $found duplicate OID(s) in catalog data\n" if $found;
-# Oids not specified in the input files are automatically assigned,
+# OIDs not specified in the input files are automatically assigned,
# starting at FirstGenbkiObjectId, extending up to FirstBootstrapObjectId.
+# We allow such OIDs to be assigned independently within each catalog.
my $FirstGenbkiObjectId =
Catalog::FindDefinedSymbol('access/transam.h', $include_path,
'FirstGenbkiObjectId');
my $FirstBootstrapObjectId =
Catalog::FindDefinedSymbol('access/transam.h', $include_path,
'FirstBootstrapObjectId');
-my $GenbkiNextOid = $FirstGenbkiObjectId;
+# Hash of next available OID, indexed by catalog name.
+my %GenbkiNextOids;
# Fetch some special data that we will substitute into the output file.
# Assign oid if oid column exists and no explicit assignment in row
if ($attname eq "oid" and not defined $bki_values{$attname})
{
- $bki_values{$attname} = $GenbkiNextOid;
- $GenbkiNextOid++;
+ $bki_values{$attname} = assign_next_oid($catname);
}
# Replace OID synonyms with OIDs per the appropriate lookup rule.
# 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 system_constraints.sql
foreach my $c (@system_constraints)
return $name . $arraystr . 'OID';
}
+# Assign an unused OID within the specified catalog.
+sub assign_next_oid
+{
+ my $catname = shift;
+
+ # Initialize, if no previous request for this catalog.
+ $GenbkiNextOids{$catname} = $FirstGenbkiObjectId
+ if !defined($GenbkiNextOids{$catname});
+
+ my $result = $GenbkiNextOids{$catname}++;
+
+ # Check that we didn't overrun available OIDs
+ die
+ "genbki OID counter for $catname reached $result, overrunning FirstBootstrapObjectId\n"
+ if $result >= $FirstBootstrapObjectId;
+
+ return $result;
+}
+
sub usage
{
die <<EOM;
* 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
* ----------
*/
#define FirstGenbkiObjectId 10000
-#define FirstBootstrapObjectId 13000
+#define FirstBootstrapObjectId 12000
#define FirstNormalObjectId 16384
/*
*/
/* yyyymmddN */
-#define CATALOG_VERSION_NO 202105271
+#define CATALOG_VERSION_NO 202105272
#endif
projects / users / gsingh / postgres.git / commitdiff