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
-
Fix issues in binary_upgrade_logical_slot_has_caught_up().
- 0bf62460bb9e 17.0 landed
-
Fix a random failure in 003_logical_slots.pl.
- 63c5df126abb 17.0 landed
-
Fix a test in 003_logical_slots.
- 3e36e48d8efe 17.0 landed
-
Fix uninitialized slot array access during the upgrade.
- a7db71ed2787 17.0 landed
-
Fix the test 003_logical_slots.
- 8af917be6bad 17.0 landed
-
Commit b195e6d482 forgot to update meson.build.
- 8949b978ff49 17.0 landed
-
Use shorter file names in the upgrade logical slots test.
- b195e6d482b8 17.0 landed
-
Migrate logical slots to the new node during an upgrade.
- 29d0a77fa660 17.0 landed
-
Flush logical slots to disk during a shutdown checkpoint if required.
- e0b2eed047df 17.0 landed
-
Prevent possibility of panics during shutdown checkpoint.
- c6c333436491 10.0 cited