On Sat, Feb 14, 2026 at 8:37 AM Chao Li <[email protected]> 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
v6-0001-Make-GUC-wal_receiver_timeout-user-settable.patch
Description: Binary data
v6-0002-Add-per-subscription-wal_receiver_timeout-setting.patch
Description: Binary data
