Re: automatically assigning catalog toast oids

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> I'm a bit dubious that this is a good idea. It's handy, at least for
> forensic situations, that the system catalogs have stable OIDs.

> Hm, but won't they have that for major versions anyway? We ought not to
> change the .bki generation in a way that results in differing oids after
> a release, no?

Well, that's just a different very-easily-broken assumption. There are
a lot of things that make auto-assigned OIDs unstable, and I do not think
that we want to guarantee that they'll hold still across a release series.

BTW, now that I'm looking at it, I very much dislike the way commit
578b2297 handled auto-assignment of OIDs in catalogs. Not only do I not
want to assign more OIDs that way, I don't think we can safely ship v12
like this. There's basically nothing at all that guarantees
genbki-assigned OIDs won't overlap initdb-assigned OIDs. In fact,
I think it's about guaranteed to blow up in the face of anybody who
inserts manually-assigned OIDs above around 9000.

What we probably need to do is restructure the FirstBootstrapObjectId
business so that there are separate, well-defined ranges for genbki.pl
and initdb to use.

regards, tom lane