On Wed, Jun 29, 2022 at 01:17:33PM +0900, Michael Paquier wrote:
> On Sat, Jun 25, 2022 at 11:04:37AM -0500, Justin Pryzby wrote:
>
> > I'll concede that a cluster which has no tables sounds a lot like a toy, but I
> > find it disturbing that nothing prevents running the process twice, up to the
> > point that it's evidently corrupted the catalog.
>
> I have heard of cases where instances were only used with a set of
> foreign tables, for example. Not sure that this is spread enough to
> worry about, but this would fail as much as your case.
foreign tables have OIDs too.
ts=# SELECT * FROM pg_class WHERE relkind ='f';
oid | 1554544611
> > While looking at this, I noticed that starting postgres --single immediately
> > after initdb allows creating objects with OIDs below FirstNormalObjectId
> > (thereby defeating pg_upgrade's check). I'm not familiar with the behavioral
> > differences of single user mode, and couldn't find anything in the
> > documentation.
>
> This one comes from NextOID in the control data file after a fresh
> initdb, and GetNewObjectId() would enforce that in a postmaster
> environment to be FirstNormalObjectId when assigning the first user
> OID. Would you imply an extra step at the end of initdb to update the
> control data file of the new cluster to reflect FirstNormalObjectId?
I added a call to reset xlog, similar to what's in pg_upgrade.
Unfortunately, I don't see an easy way to silence it.
--
Justin
