Re: pg_upgrade's interaction with pg_resetwal seems confusing

On Fri, Oct 13, 2023 at 2:03 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Fri, Oct 13, 2023 at 11:07 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > > But is this a problem? basically, we will set the
> > > ShmemVariableCache->nextOid counter to the value that we want in the
> > > IsBinaryUpgrade-specific function. And then the shutdown checkpoint
> > > will flush that value to the control file and that is what we want no?
> > >
> >
> > I think that can work. Basically, we need to do something like what
> > SetNextObjectId() does and then let the shutdown checkpoint update the
> > actual value in the control file.
>
> Right.
>
> > > 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.

--
With Regards,
Amit Kapila.