Re: [PoC] pg_upgrade: allow to upgrade publisher node - Mailing list pgsql-hackers

On Fri, Aug 11, 2023 at 11:38 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Fri, Aug 11, 2023 at 10:46:31AM +0530, Amit Kapila wrote:
> > On Thu, Aug 10, 2023 at 7:07 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > What I imagined is that we do this check before
> > > check_and_dump_old_cluster() while the server is 'off'. Reading the
> > > slot state file would be simple and I guess we would not need a tool
> > > or cli program for that. We need to expose RepliactionSlotOnDisk,
> > > though.
> >
> > Won't that require a lot of version-specific checks as across versions
> > the file format could be different? For the case of the control file,
> > we use version-specific pg_controldata (for the old cluster, the
> > corresponding version's pg_controldata) utility to read the old
> > version control file. I thought we need something similar here if we
> > want to do what you are suggesting.
>
> You mean the slot file format?

Yes.

>
>  We will need that complexity somewhere,
> so why not in pg_upgrade?
>

I don't think we need the complexity of version-specific checks if we
do what we do in get_control_data(). Basically, invoke
version-specific pg_replslotdata to get version-specific slot
information. There has been a proposal for a tool like that [1]. Do
you have something better in mind? If so, can you please explain the
same a bit more?

> > > After reading the control file and the slots' state files we
> > > check if slot's confirmed_flush_lsn matches the latest checkpoint LSN
> > > in the control file (BTW maybe we can get slot name and plugin name
> > > here instead of using pg_dump?).
> >
> > But isn't the advantage of doing via pg_dump (in binary_mode) that we
> > allow some outside core in-place upgrade tool to also use it if
> > required? If we don't think that would be required then we can
> > probably use the info we retrieve it in pg_upgrade.
>
> You mean the code reading the slot file?  I don't see the point of
> adding user complexity to enable some hypothetical external usage.
>

It is not just that we need a slot reading facility but rather mimic
something like pg_get_replication_slots() where we have to know the
walstate (WALAVAIL_REMOVED, etc.) as well. I am not against it but am
not sure that we do it for any other object in the upgrade. Can you
please point me out if we have any such prior usage? Even if we don't
do it today, we can start doing now if that makes sense but it appears
to me that we are accessing contents of data-dir/WAL by invoking some
other utilities like pg_controldata, pg_resetwal, so something similar
would make sense here. Actually, what we do here also somewhat depends
on what we decide for the other point we are discussing above in the
email.

[1] -
https://www.postgresql.org/message-id/flat/CALj2ACW0rV5gWK8A3m6_X62qH%2BVfaq5hznC%3Di0R5Wojt5%2Byhyw%40mail.gmail.com

--
With Regards,
Amit Kapila.