Re: automatically assigning catalog toast oids

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: automatically assigning catalog toast oids
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_partition_tree crashes for a non-defined relation