Re: Make wal_receiver_timeout configurable per subscription

On Sat, Feb 14, 2026 at 8:37 AM Chao Li <li.evan.chao@gmail.com> wrote:
> I realized atoi(“-1invalid”) would return -1, but I thought that would be an imagined use case. I’m fine if you insist to use parse_int. Maybe we can enhance the comment. set_config_option does the test and parse_int is used to skip -1.

IMO the current comment is sufficient, so I left it unchanged.

+ /* 180000 should be changed to 190000 */
+ if (pset.sversion >= 180000)
+ appendPQExpBuffer(&buf,

Since I started the patch before v19dev was created, I temporarily used
180000 and planned to update it to 190000 later, but forgot to do so.
This is now fixed.

+ /*
+ * Log the current wal_receiver_timeout GUC value (in milliseconds) as a
+ * debug message to verify it was set correctly.
+ */
+ elog(DEBUG1, "logical replication worker for subscription \"%s\"
wal_receiver_timeout: %d ms",
+ MySubscription->name, wal_receiver_timeout);

Previously, this debug message was emitted every time set_wal_receiver_timeout()
was called, even when the value had not changed. For example,
ALTER SUBSCRIPTION ... SET (synchronous_commit = true) would trigger
the message, which seemed strange. I updated the code so the message is
logged only when the effective wal_receiver_timeout value used by
the worker actually changes.

Attached are the updated patches.

Regards,

-- 
Fujii Masao