Re: Replacing pg_depend PIN entries with a fixed range check

On Wed, May 26, 2021 at 11:37 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I think that particular case is definitely worth worrying about. Most
of what we put into the system catalogs is our own hand-crafted
entries, but that's coming from the operating system and we have no
control over it whatever. It wouldn't be very nice to have to suggest
to users who get can't initdb that perhaps they should delete some
locales...

Honestly, it seems odd to me that these entries use reserved OIDs
rather than regular ones at all. Why does the first run of
pg_import_system_collations use special magic OIDs, and later runs use
regular OIDs? pg_type OIDs need to remain stable from release to
release since it's part of the on disk format for arrays, and pg_proc
OIDs have to be the same at compile time and initdb time because of
the fmgr hash table, and any other thing that has a constant that
might be used in the source code also has that issue. But none of this
applies to collations: they can't expected to have the same OID from
release to release, or even from one installation to another; the
source code can't be relying on the specific values; and we have no
idea how many there might be.

So I think your proposal of allowing genbki-assigned OIDs to be reused
in different catalogs is probably a pretty good one, but I wonder if
we could just rejigger things so that collations just get normal OIDs
> 16384.

--
Robert Haas
EDB: http://www.enterprisedb.com