Re: Make wal_receiver_timeout configurable per subscription
Japin Li <japinli@hotmail.com>
From: Japin Li <japinli@hotmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Amit Kapila
<amit.kapila16@gmail.com>, vignesh C <vignesh21@gmail.com>, Michael
Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2026-02-06T01:50:27Z
Lists: pgsql-hackers
On Thu, 05 Feb 2026 at 23:40, Fujii Masao <masao.fujii@gmail.com> wrote: > On Thu, Feb 5, 2026 at 1:06 PM Japin Li <japinli@hotmail.com> wrote: >> Thanks for updating the patches. >> I have one small comment on v4-0002: > > Thanks for the review! > > >> @@ -104,6 +105,7 @@ typedef struct SubOpts >> int32 maxretention; >> char *origin; >> XLogRecPtr lsn; >> + char *wal_receiver_timeout; >> } SubOpts; >> >> According to the comment above the SubOpts struct: >> >> Structure to hold a bitmap representing the user-provided CREATE/ALTER >> SUBSCRIPTION command options and the parsed/default values of each of them. >> >> Since `wal_receiver_timeout` is a GUC-style interval value (typically stored as >> integer milliseconds), wouldn't it be better to use an int32 here instead of a >> string? > > The wal_receiver_timeout value in CREATE SUBSCRIPTION can include a unit > (for example, 10s), not just a plain integer. Because of that, we can't store it > in an int32, I think. > If we stored it as an integer, an input such as '1min' would be normalized to 60000 (milliseconds) and lose its unit. That would make it inconsistent with the original user input shown in pg_subscription. So we keep it as a string, right? > Regards, > > -- > Fujii Masao -- Regards, Japin Li ChengDu WenWu Information Technology Co., Ltd.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add per-subscription wal_receiver_timeout setting.
- fb80f388f4a1 19 (unreleased) landed
-
Make GUC wal_receiver_timeout user-settable.
- 8a6af3ad0879 19 (unreleased) landed