Re: [PoC] pg_upgrade: allow to upgrade publisher node
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Dilip Kumar <dilipbalaut@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Bruce Momjian <bruce@momjian.us>, Julien Rouhaud <rjuju123@gmail.com>, vignesh C <vignesh21@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2023-10-05T13:13:30Z
Lists: pgsql-hackers
On Thu, Oct 5, 2023 at 1:48 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > Then, we should also try to create slots before invoking pg_resetwal. > The idea is that we can write a new binary mode function that will do > exactly what pg_resetwal does to compute the next segment and use that > location as a new location (restart_lsn) to create the slots in a new > node. Then, pass it pg_resetwal by using the existing option '-l > walfile'. As we don't have any API that takes restart_lsn as input, we > can write a new API probably for binary mode to create slots that do > take restart_lsn as input. This will ensure that there is no new WAL > inserted by background processes between resetwal and the creation of > slots. +1. I think this approach makes it foolproof. pg_resetwal uses FindEndOfXLOG and we need that to be in a binary mode SQL callable function. FindEndOfXLOG ignores TLI to compute the new WAL file name, but that seems to be okay for the new binary mode function because pg_upgrade uses TLI 1 anyways and doesn't copy WAL files from old cluster. FWIW, pg_upgrades does use -l in copy_xact_xlog_xid, I'm not sure if it has anything to do with the above proposed change. > The other potential problem Andres pointed out is that during shutdown > if due to some reason, the walreceiver goes down, we won't be able to > send the required WAL and users won't be able to ensure that because > even after restart the same situation can happen. The ideal way is to > have something that puts the system in READ ONLY state during shutdown > and then we can probably allow walreceivers to reconnect and receive > the required WALs. As we don't have such functionality available and > it won't be easy to achieve the same, we can leave this for now. > > Thoughts? You mean walreceiver for streaming replication? Or the apply workers going down for logical replication? If there's yet-to-be-sent-out WAL, pg_upgrade will fail no? How does the above scenario a problem for pg_upgrade of a cluster with just logical replication slots? -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
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