Re: [PoC] pg_upgrade: allow to upgrade publisher node
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: 'vignesh C' <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2023-04-24T14:22:56Z
Lists: pgsql-hackers
Hi, On Mon, Apr 24, 2023 at 12:03:05PM +0000, Hayato Kuroda (Fujitsu) wrote: > > > I think that this test should be different when just checking for the > > prerequirements (live_check / --check) compared to actually doing the upgrade, > > as it's almost guaranteed that the slots won't have sent everything when the > > source server is up and running. > > Hmm, you assumed that the user application is still running and data is coming > continuously when doing --check, right? Personally I have thought that the > --check operation is executed just before the actual upgrading, therefore I'm not > sure your assumption is real problem. The checks are always executed before doing the upgrade, to prevent it if something isn't right. But you can also just do those check on a live instance, so you can get a somewhat strong guarantee that the upgrade operation will succeed before needing to stop all services and shut down postgres. It's basically free to run those checks and can avoid an unnecessary service interruption so I'm pretty sure people use it quite often. > And I could not find any checks which their > contents are changed based on the --check option. Yes, because other checks are things that you can actually fix when the instance is running, like getting rid of tables with oids. The only semi exception if for 2pc which can be continuously prepared and committed, but if you hit that problem at least you know you have to stop cleanly your XA-like application and make sure there are no 2pc left. > Yeah, if we support the case checking pg_replication_slots.active may be sufficient. > Actually this cannot handle the case that pg_create_logical_replication_slot() > is executed just before upgrading, but I'm not sure it should be. It shouldn't, same for any of the other checks. The live check can't predict the future, it just tells you if there's anything that would prevent the upgrade *at the moment it's executed*.
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