RE: pg_upgrade's interaction with pg_resetwal seems confusing

Dear hackers,

> >
> > > > I mean instead of resetwal directly modifying the control file we
> > > > will modify that value in the server using the binary_upgrade function
> > > > and then have that value flush to the disk by shutdown checkpoint.
> > > >
> > >
> > > True, the alternative to consider is to let pg_upgrade update the
> > > control file by itself with the required value of OID. The point I am
> > > slightly worried about doing via server-side function is that some
> > > online and or shutdown checkpoint can update other values in the
> > > control file as well whereas if we do via pg_upgrade, we can have
> > > better control over just updating the OID.
> >
> > Yeah, thats a valid point.
> >
>
> But OTOH, just updating the control file via pg_upgrade may not be
> sufficient because we should keep the shutdown checkpoint record also
> updated with that value. See how pg_resetwal achieves it via
> RewriteControlFile() and WriteEmptyXLOG(). So, considering both the
> approaches it seems better to go with a server-side function as Robert
> suggested.

Based on these discussion, I implemented a server-side approach. An attached patch
adds a upgrade function which sets ShmemVariableCache->nextOid. It is called at
the end of the upgrade. Comments and name of issue_warnings_and_set_wal_level()
is also updated because they become outdated.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED