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