Re: Make wal_receiver_timeout configurable per subscription - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Make wal_receiver_timeout configurable per subscription
Date
Msg-id CAHGQGwGNJbFhPnG=dUxkdKiHdh0Hu-+UDgN=73MKL-aBio6cfw@mail.gmail.com
Whole thread
In response to Re: Make wal_receiver_timeout configurable per subscription  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: Make wal_receiver_timeout configurable per subscription
List pgsql-hackers
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
insistto 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

Attachment

pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: pgstat include expansion
Next
From: Heikki Linnakangas
Date:
Subject: Re: Refactoring postmaster's code to cleanup after child exit