Re: removing datlastsysoid

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: removing datlastsysoid
Дата
Msg-id e3ab390c-0090-7765-f8f9-9cc18c171d63@pgmasters.net
обсуждение исходный текст
Ответ на Re: removing datlastsysoid  (Dave Page <dpage@pgadmin.org>)
Ответы Re: removing datlastsysoid  (Dave Page <dpage@pgadmin.org>)
Список pgsql-hackers
On 5/16/22 9:43 AM, Dave Page wrote:
> 
> 
> On Thu, 20 Jan 2022 at 14:03, Robert Haas <robertmhaas@gmail.com 
> <mailto:robertmhaas@gmail.com>> wrote:
> 
>     On Mon, Jan 17, 2022 at 3:43 PM Tom Lane <tgl@sss.pgh.pa.us
>     <mailto:tgl@sss.pgh.pa.us>> wrote:
>      > +1.  Another reason to get rid of it is that it has nothing to do
>      > with the system OID ranges defined in access/transam.h.
> 
>     Agreed. Thanks for looking. Committed.
> 
> 
> So we just ran into this whilst updating pgAdmin to support PG15. How is 
> one supposed to figure out what the last system OID is now from an 
> arbitrary database? pgAdmin uses that value in well over 300 places in 
> its source.

We ran into the same issue in pgBackRest. The old query that initdb used 
to generate these values is no good for PG15 since the template 
databases now have fixed low oids.

Out solution was to use the constant:

#define FirstNormalObjectId        16384

And treat anything below that as a system oid. This constant has not 
changed in a very long time (if ever) but we added it to our list of 
constants to recheck with each release.

We used the initdb query to provide backward compatibility for older 
versions of pgbackrest using PG <= 14, but are using FirstNormalObjectId 
going forward.

See 
https://github.com/pgbackrest/pgbackrest/commit/692fe496bdb5fa6dcffeb9f85b6188ceb1df707a 
for details.

Regards,
-- 
-David
david@pgmasters.net



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

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: removing datlastsysoid
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: First draft of the PG 15 release notes