Re: pg_upgrade's interaction with pg_resetwal seems confusing

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Hou, Zhijie/侯 志杰 <houzj(dot)fnst(at)fujitsu(dot)com>
Subject: Re: pg_upgrade's interaction with pg_resetwal seems confusing
Date: 2023-10-13 05:36:54
Message-ID: CAA4eK1+YzQuArCFEUMzQWNB3hC3sg03bje_cWeLhJ=ygemkUdw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 13, 2023 at 10:37 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Fri, Oct 13, 2023 at 9:29 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Oct 13, 2023 at 12:00 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > >
> > > On Thu, Oct 12, 2023 at 7:17 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-10-13 05:37:14 Re: PostgreSQL domains and NOT NULL constraint
Previous Message Michael Paquier 2023-10-13 05:31:22 Re: Tab completion for AT TIME ZONE