On Wed, May 26, 2021 at 11:37 AM Tom Lane <t...@sss.pgh.pa.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
