Re: Make wal_receiver_timeout configurable per subscription
От | Fujii Masao |
---|---|
Тема | Re: Make wal_receiver_timeout configurable per subscription |
Дата | |
Msg-id | adf8214d-f2ae-4777-9ba0-33f18ab77e0b@oss.nttdata.com обсуждение исходный текст |
Ответ на | Make wal_receiver_timeout configurable per subscription (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Список | 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.fujii@oss.nttdata.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
Вложения
В списке pgsql-hackers по дате отправления: