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