Re: automatically assigning catalog toast oids
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2018-12-09T22:14:42Z
Lists: 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
Commits
-
Fix typo in transam.h for OIDs assigned by genbki.pl
- f0cce9fcb5fd 12.0 landed
-
Create a separate oid range for oids assigned by genbki.pl.
- 09568ec3d31b 12.0 landed
-
Remove WITH OIDS support, change oid catalog column visibility.
- 578b229718e8 12.0 cited
-
Add toast tables to most system catalogs
- 96cdeae07f93 12.0 cited