Re: Replacing pg_depend PIN entries with a fixed range check

Robert Haas <robertmhaas(at)gmail(dot)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'm sort of wondering what we think the long term plan ought to be.
> Are there some categories of things we should be looking to move out
> of the reserved OID space to keep it from filling up? Can we
> realistically think of moving the 16384 boundary?

I haven't got any wonderful ideas there. I do not see how we can
move the 16384 boundary without breaking pg_upgrade'ing, because
pg_upgrade relies on preserving user object OIDs that are likely
to be not much above that value. Probably, upping
FirstNormalObjectId ought to be high on our list of things to do
if we ever do force an on-disk compatibility break. In the
meantime, we could decrease the 10000 boundary if things get
tight above that, but I fear that would annoy some extension
maintainers.

Another idea is to give up the principle that initdb-time OIDs
need to be globally unique. They only really need to be
unique within their own catalogs, so we could buy a lot of space
by exploiting that. The original reason for that policy was to
reduce the risk of mistakes in handwritten OID references in
the initial catalog data --- but now that numeric references
there are Not Done, it seems like we don't really need that.

An intermediate step, perhaps, could be to give up that
uniqueness only for OIDs assigned by genbki.pl itself, while
keeping it for OIDs below 10000. This'd be appealing if we
find that we're getting tight between 10K and 13K.

In any case it doesn't seem like the issue is entirely pressing
yet. Although ... maybe we should do that last bit now, so
that we can revert FirstBootstrapObjectId to 12K before v14
ships? I've felt a little bit of worry that that change might
cause problems on machines with a boatload of locales.

regards, tom lane