Re: [PoC] pg_upgrade: allow to upgrade publisher node

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Julien Rouhaud <rjuju123@gmail.com>, vignesh C <vignesh21@gmail.com>
Date: 2023-08-14T02:27:20Z
Lists: pgsql-hackers
On Sat, Aug 12, 2023, 15:20 Amit Kapila <amit.kapila16@gmail.com> wrote:

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

Yeah, we need something like pg_replslotdata. If there are other useful
usecases for this tool, it would be good to have it. But I'm not sure other
than pg_upgrade usecase.

Another idea is (which might have already discussed thoguh) that we check
if the latest shutdown checkpoint LSN in the control file matches the
confirmed_flush_lsn in pg_replication_slots view. That way, we can ensure
that the slot has consumed all WAL records before the last shutdown. We
don't need to worry about WAL records generated after starting the old
cluster during the upgrade, at least for logical replication slots.

Regards,

Commits

  1. Fix issues in binary_upgrade_logical_slot_has_caught_up().

  2. Fix a random failure in 003_logical_slots.pl.

  3. Fix a test in 003_logical_slots.

  4. Fix uninitialized slot array access during the upgrade.

  5. Fix the test 003_logical_slots.

  6. Commit b195e6d482 forgot to update meson.build.

  7. Use shorter file names in the upgrade logical slots test.

  8. Migrate logical slots to the new node during an upgrade.

  9. Flush logical slots to disk during a shutdown checkpoint if required.

  10. Prevent possibility of panics during shutdown checkpoint.