Re: automatically assigning catalog toast oids

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: automatically assigning catalog toast oids
Дата
Msg-id 16845.1544393682@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: automatically assigning catalog toast oids  (Andres Freund <andres@anarazel.de>)
Ответы Re: automatically assigning catalog toast oids  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: automatically assigning catalog toast oids
Следующее
От: Andres Freund
Дата:
Сообщение: Re: automatically assigning catalog toast oids