Re: pg_upgrade allows itself to be run twice

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