From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Stephen Frost <sfrost@snowman.net>, John Naylor <jcnaylor@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: automatically assigning catalog toast oids
In-reply-to: <20181209211741.5ohnwu7q4aycvm2t@alap3.anarazel.de>
References: 
 <CAJVSVGWjRjY6Kg+sriZitkVVjjH8i4uEyVrQf1bwdu2z61=XLQ@mail.gmail.com>
 <18075.1544380583@sss.pgh.pa.us> <20181209204257.GH3415@tamriel.snowman.net>
 <20181209211741.5ohnwu7q4aycvm2t@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sun, 09 Dec 2018 13:17:41 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16844.1544393682.1@sss.pgh.pa.us>
Date: Sun, 09 Dec 2018 17:14:42 -0500
Message-ID: <16845.1544393682@sss.pgh.pa.us>
Precedence: bulk

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.

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