Re: automatically assigning catalog toast oids - Mailing list pgsql-hackers

From Andres Freund
Subject Re: automatically assigning catalog toast oids
Date
Msg-id 20181209223330.roso4ubdfvshzpwy@alap3.anarazel.de
Whole thread Raw
In response to Re: automatically assigning catalog toast oids  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: automatically assigning catalog toast oids  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
> >> * Tom Lane (tgl@sss.pgh.pa.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.

Why wouldn't they be for genbki (rather than initdb) assigned oids?  I
don't think it's reasonable to add new functions or such post release
that would have move oid assignments for other objects?


> 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

Why do you not want that?


> , 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.

I'm not sure I really see a pressing problem with that. I think it'd not
be insane to treat this as a "well, don't do that then".


> 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.

I'm fine with adding a distinct range, the earlier version of the patch
had that. I'd asked for comments if anybody felt a need to keep that,
nobody replied...  I alternatively proposed that we could just start at
FirstNormalObjectId for those and update the server's oid start value to
the maximum genbki assigned oid.  Do you have preferences around that?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: automatically assigning catalog toast oids
Next
From: Michael Paquier
Date:
Subject: Re: pg_partition_tree crashes for a non-defined relation