Re: [PoC] pg_upgrade: allow to upgrade publisher node
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-18T09:06:51Z
Lists: pgsql-hackers
On Mon, Jul 17, 2023 at 6:19 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Jun 30, 2023 at 7:29 PM Hayato Kuroda (Fujitsu) > <kuroda.hayato@fujitsu.com> wrote: > > > > I have analyzed more, and concluded that there are no difference between manual > > and shutdown checkpoint. > > > > The difference was whether the CHECKPOINT record has been decoded or not. > > The overall workflow of this test was: > > > > 1. do INSERT > > (2. do CHECKPOINT) > > (3. decode CHECKPOINT record) > > 4. receive feedback message from standby > > 5. do shutdown CHECKPOINT > > > > At step 3, the walsender decoded that WAL and set candidate_xmin_lsn. The stucktrace was: > > standby_decode()->SnapBuildProcessRunningXacts()->LogicalIncreaseXminForSlot(). > > > > At step 4, the confirmed_flush of the slot was updated, but ReplicationSlotSave() > > was executed only when the slot->candidate_xmin_lsn had valid lsn. If step 2 and > > 3 are misssed, the dirty flag is not set and the change is still on the memory. > > > > FInally, the CHECKPOINT was executed at step 5. If step 2 and 3 are misssed and > > the patch from Julien is not applied, the updated value will be discarded. This > > is what I observed. The patch forces to save the logical slot at the shutdown > > checkpoint, so the confirmed_lsn is save to disk at step 5. > > > > I see your point but there are comments in walsender.c which indicates > that we also wait for step-5 to get replicated. See [1] and comments > atop walsender.c. If this is true then we don't need a special check > as you have in patch 0003 or at least it doesn't seem to be required > in all cases. > I have studied this a bit more and it seems that is true for physical walsenders where we set the state of walsender as WALSNDSTATE_STOPPING in XLogSendPhysical, then the checkpointer finishes writing checkpoint record and then postmaster sends SIGUSR2 for walsender to exit. IIUC, this whole logic of different stop states has been introduced in commit c6c3334364 based on the discussion in the thread [1]. As per my understanding, logical walsenders don't seem to be waiting for shutdown checkpoint record and finishes before even we LOG that record. It seems that the behavior of logical walsenders is different from physical walsenders where we wait for them to send even the final shutdown checkpoint record before they finish. If so, then we won't be able to switchover to logical subscribers even in case of a clean shutdown. Am, I missing something? [1] - https://www.postgresql.org/message-id/CAHGQGwEsttg9P9LOOavoc9d6VB1zVmYgfBk%3DLjsk-UL9cEf-eA%40mail.gmail.com -- With Regards, Amit Kapila.
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