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

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, "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-11T18:08:39Z
Lists: pgsql-hackers
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?  We will need that complexity somewhere,
so why not in pg_upgrade?

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

> > the first commit. Or another idea would be to allow users to mark
> > replication slots "upgradable" so that pg_upgrade skips the
> > confirmed_flush_lsn check.
> 
> I guess for that we need to ask users to ensure that confirm_flush_lsn
> is up-to-date and then provide some slot-level API to mark the slots
> with the required status. If so, that sounds a bit complicated for
> users.

Agreed, not worth it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



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.