Re: Replacing pg_depend PIN entries with a fixed range check

I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> The first hunk of the patch seems to back away from the idea that the
>> cutoff is 13000, but the second half of the patch says 13000 still
>> matters. Not sure I understand what's going on there exactly.

> Not sure exactly what you're looking at, but IIRC there is a place
> where the patch is cleaning up after ab596105b's failure to adjust
> bki.sgml to match its change of FirstBootstrapObjectId from 12000
> to 13000.  I hadn't bothered to fix that separately, but I guess
> we should do so, else v14 is going to ship with incorrect docs.

I take that back: I had committed that doc fix, in 1f9b0e693, so
I'm still unsure what was confusing you.  (But a4390abec just
reverted it, anyway.)

Attached is a rebase over a4390abec.  The decision in that commit
to not expect global uniqueness of OIDs above 10K frees us to use
a much simpler solution than before: we can just go ahead and start
the backend's OID counter at 10000, and not worry about conflicts,
because the OID generation logic can deal with any conflicts just
fine as long as you're okay with only having per-catalog uniqueness.
So this gets rid of the set_next_oid mechanism that I'd invented in
v2, and yet there's still no notable risk of running out of OIDs in
the 10K-12K range.

While testing this, I discovered something that I either never knew
or had forgotten: the bootstrap backend is itself assigning some
OIDs, specifically OIDs for the composite types associated with most
of the system catalogs (plus their array types).  I find this scary,
because it is happening before we've built the catalog indexes, so
it's impossible to ensure uniqueness.  (Of course, when we do build
the indexes, we'd notice any conflicts; but that's not a solution.)
I think it accidentally works because we don't ask genbki.pl to
assign any pg_type OIDs, but that seems fragile.  Seems like maybe
we should fix genbki.pl to assign those OIDs, and then change
GetNewOidWithIndex to error out in bootstrap mode.  However that's a
pre-existing issue, so I don't feel that this patch needs to be
the one to fix it.

			regards, tom lane