On Wed, Oct 21, 2026 at 10:47 AM Amit Kapila <[email protected]> wrote: > > On Wed, Oct 21, 2026 at 6:09 AM shihao zhong <[email protected]> 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
