| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Manu <manuelreyesbravo(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com> |
| Subject: | Re: [PG19] Promotion hangs behind a backend blocked on a stuck client |
| Date: | 2026-10-19 00:13:57 |
| Message-ID: | CAGRkXqRFJnMZ41n6=xBg+KrWcJ7PmWzPjHJ8N4BfLe_ROY_yhQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Masahiko,
I would still like 0001 in 19, because the cases that remain are the
HA ones.
After 239c4d30699 the wait only happens when the standby has a logical
slot, and Manu measured that a failover slot synced by the slotsync
worker is enough. That is exactly the setup of an HA cluster that
keeps logical replication across failover.
A network split or a dead app host leaves such a client behind.
Promotion then waits until TCP gives up, which may took up to 15 minutes
The workarounds need someone to know about this ahead of time, and
most failover tools do not terminate backends before promoting.
If you still prefer master only, I am fine with it and we need to
add that into the doc note for 19.
Thanks,
Shihao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-10-19 00:39:29 | Re: First draft of PG 19 release notes |
| Previous Message | shihao zhong | 2026-10-19 00:06:04 | Re: [PG19] pg_dump --statistics restores extended statistics by attribute number |