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 |
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 |