Re: pg_upgrade's interaction with pg_resetwal seems confusing - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: pg_upgrade's interaction with pg_resetwal seems confusing
Date
Msg-id CAFiTN-tMdyNUDKet8WMP32e+FtuDf0aRbYUJ3zVR5fs1chfqGg@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade's interaction with pg_resetwal seems confusing  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pg_upgrade's interaction with pg_resetwal seems confusing
List pgsql-hackers
On Fri, Oct 13, 2023 at 11:07 AM Amit Kapila <amit.kapila16@gmail.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.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: On login trigger: take three
Next
From: shveta malik
Date:
Subject: Re: Synchronizing slots from primary to standby