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

On Wed, Oct 21, 2026 at 10:47 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Oct 21, 2026 at 6:09 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
> >
> > I agree. 19 gets a note in the docs, and v6 goes to master first.
> >
> > The docs patch for 19 is attached. It says what blocks, how to see the
> > PID, and how to get out. I am happy to change the wording.
> >
>
> <para>
> + To avoid the wait, set <varname>wal_level</varname> to
> + <literal>logical</literal> on the standby.
>
> Will this help when the promotion is stuck? I feel this defeats the
> purpose of the feature introduced in commit 67c20979ce7.

+1.

I like the doc idea on PG19 and the patch 'fix_doc.1'. A few comments:

1)
+ <literal>replica</literal> that has a logical replication slot at the end
+1 on what Kuroda-san pointed. I think we should mention 'valid' slots

2)
It would be better to link tcp_user_timeout (and wal_level) rather
than only naming it, so readers can find the platform and Unix-socket
restrictions.

3)
+ To bound such waits in advance, set
+ <varname>tcp_user_timeout</varname> on the standby, where supported by
+ the operating system. The setting takes effect only for connections
+ established after it is configured, and does not affect a connection
+ whose backend is already blocked.

Shall we change to:

To bound such waits in advance, set tcp_user_timeout on the standby;
it applies only to TCP connections, on platforms that support it.
After a configuration reload, an existing session picks up the new
value when its client sends the next query. Consequently, the setting
does not affect a backend that is already blocked.

thanks
Shveta