Re: pg_upgrade's interaction with pg_resetwal seems confusing

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: pg_upgrade's interaction with pg_resetwal seems confusing
Дата
Msg-id CAA4eK1J54Qz3_YbqPUKhuv7NnxHjOZ+tXzDw9QPxTYKZMSWZTg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade's interaction with pg_resetwal seems confusing  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы RE: pg_upgrade's interaction with pg_resetwal seems confusing  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Список pgsql-hackers
On Fri, Oct 13, 2023 at 2:03 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> 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.
>

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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrei Lepikhov
Дата:
Сообщение: Re: Oversight in reparameterize_path_by_child leading to executor crash
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: BRIN minmax multi - incorrect distance for infinite timestamp/date