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

From Japin Li
Subject Re: Make wal_receiver_timeout configurable per subscription
Date
Msg-id MEAPR01MB3031DBC0F26623BD2A3389A2B666A@MEAPR01MB3031.ausprd01.prod.outlook.com
Whole thread Raw
In response to Make wal_receiver_timeout configurable per subscription  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Make wal_receiver_timeout configurable per subscription
List 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.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: client_connection_check_interval default value
Next
From: Thomas Munro
Date:
Subject: Re: Decoupling our alignment assumptions about int64 and double