On Mon, 16 May 2022 at 15:06, David Steele <da...@pgmasters.net> wrote:
> On 5/16/22 9:43 AM, Dave Page wrote: > > > > > > On Thu, 20 Jan 2022 at 14:03, Robert Haas <robertmh...@gmail.com > > <mailto:robertmh...@gmail.com>> wrote: > > > > On Mon, Jan 17, 2022 at 3:43 PM Tom Lane <t...@sss.pgh.pa.us > > <mailto:t...@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. > Yes, that seems reasonable. Changing that value would very likely break pg_upgrade I can imagine, so I suspect it'll stay as it is for a while longer. > > 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. > Thanks David! -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com
