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

From Amit Kapila
Subject Re: pg_upgrade's interaction with pg_resetwal seems confusing
Date
Msg-id CAA4eK1+YzQuArCFEUMzQWNB3hC3sg03bje_cWeLhJ=ygemkUdw@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade's interaction with pg_resetwal seems confusing  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: pg_upgrade's interaction with pg_resetwal seems confusing
List pgsql-hackers
On Fri, Oct 13, 2023 at 10:37 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Fri, Oct 13, 2023 at 9:29 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Oct 13, 2023 at 12:00 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > >
> > > On Thu, Oct 12, 2023 at 7:17 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > > Now, as mentioned in the first paragraph, it seems we anyway don't
> > > > need to reset the WAL at the end when setting the next OID for the new
> > > > cluster with the -o option. If that is true, then I think even without
> > > > slots work it will be helpful to have such an option in pg_resetwal.
> > > >
> > > > Thoughts?
> > >
> > > I wonder if we should instead provide a way to reset the OID counter
> > > with a function call inside the database, gated by IsBinaryUpgrade.
> > >
> >
> > I think the challenge in doing so would be that when the server is
> > running, a concurrent checkpoint can also update the OID counter value
> > in the control file. See below code:
> >
> > CreateCheckPoint()
> > {
> > ...
> > LWLockAcquire(OidGenLock, LW_SHARED);
> > checkPoint.nextOid = ShmemVariableCache->nextOid;
> > if (!shutdown)
> > checkPoint.nextOid += ShmemVariableCache->oidCount;
> > LWLockRelease(OidGenLock);
> > ...
> > UpdateControlFile()
> > ...
> > }
> >
>
> 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.

>  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.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Tab completion for AT TIME ZONE
Next
From: Tom Lane
Date:
Subject: Re: PostgreSQL domains and NOT NULL constraint