Re: [PG19] Promotion hangs behind a backend blocked on a stuck client

Mon, 19 Oct 2026 18:26:41 -0700 

Hi Masahiko,

I think you are right, 0001 would turn the checksum barrier's retry into a
FATAL.

Option (1) can cover the failover slot case in 19. At the end of
recovery, a stale cache can only be in a process started before
StartupLogicalDecodingStatus(), like the checkpointer. Later ones read
it at startup, and a replayed enable waits for everyone. So the startup
process can emit the barrier there, and at the end of recovery wait for
that generation when the status did not change.

It does not help when replaying the enable record has to wait, or
when the end of recovery itself turns the status on. For master I
agree (2) is better, and it helps DROP DATABASE too.

Thanks,
Shihao

Attachment: v5-0002-Test-promotion-with-a-backend-blocked-on-a-stuck-.patch
Description: Binary data

Attachment: v5-0001-Skip-the-end-of-recovery-barrier-wait-when-nothin.patch
Description: Binary data

Attachment: nocfbot-v5-19-0001-Skip-the-end-of-recovery-barrier-wait-when-nothin.patch
Description: Binary data

Reply via email to