Re: Make wal_receiver_timeout configurable per subscription

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Make wal_receiver_timeout configurable per subscription
Date: 2025-07-14 13:27:13
Message-ID: adf8214d-f2ae-4777-9ba0-33f18ab77e0b@oss.nttdata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025/05/28 0:36, Fujii Masao wrote:
>
>
> On 2025/05/22 21:21, Amit Kapila wrote:
>> On Wed, May 21, 2025 at 6:04 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>>
>>> On 2025/05/20 18:13, vignesh C wrote:
>>>> If we set the wal_receiver_timeout configuration using ALTER ROLE for
>>>> the subscription owner's role, the apply worker will start with that
>>>> value. However, any changes made via ALTER ROLE ... SET
>>>> wal_receiver_timeout will not take effect for an already running apply
>>>> worker unless the subscription is disabled and re-enabled. In
>>>> contrast, this is handled automatically during CREATE SUBSCRIPTION,
>>>> where parameter changes are detected.
>>>
>>> Yes, this is one of the limitations of the user-settable wal_receiver_timeout
>>> approach. If we want to change the timeout used by the apply worker without
>>> restarting it, storing the value in pg_subscription (similar to how
>>> synchronous_commit is handled) would be a better solution.
>>>
>>> In that case, for example, we could set the default value of
>>> pg_subscription.wal_receiver_timeout to -1, meaning the apply worker should
>>> use the global wal_receiver_timeout from postgresql.conf. If the value is 0
>>> or higher, the apply worker would use the value stored in pg_subscription.
>>>
>>
>> Yeah, I had a similar idea in my mind.
>
> OK, I've implemented two patches:
>
>   - 0001 makes the wal_receiver_timeout GUC user-settable.
>   - 0002 adds support for setting wal_receiver_timeout per subscription.
>     It depends on the changes in 0001.
>
> With both patches applied, wal_receiver_timeout can be set per role or
> per database using ALTER ROLE or ALTER DATABASE (from 0001), and also
> per subscription using CREATE SUBSCRIPTION or ALTER SUBSCRIPTION (from 0002).
> The per-subscription value is stored in pg_subscription.subwalrcvtimeout,
> and it overrides the global setting of wal_receiver_timeout for that
> subscription's apply worker. The default is -1, meaning the global setting
> (from server config, command line, role, or database) is used.

I've attached the rebased patches.

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

Attachment Content-Type Size
v2-0001-Make-GUC-wal_receiver_timeout-user-settable.patch text/plain 2.0 KB
v2-0002-Add-per-subscription-wal_receiver_timeout-setting.patch text/plain 57.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2025-07-14 13:38:21 Re: speedup COPY TO for partitioned table.
Previous Message Aleksander Alekseev 2025-07-14 13:23:10 Re: Missing NULL check after calling ecpg_strdup