On Fri, Apr 14, 2017 at 9:59 PM, Petr Jelinek <[email protected]> wrote: > On 14/04/17 14:30, Michael Paquier wrote: >> On Fri, Apr 14, 2017 at 9:19 PM, Petr Jelinek >> <[email protected]> wrote: >>> I am not quite sure adding more GUCs is all that great option. When >>> writing the patches I was wondering if we should perhaps rename the >>> wal_receiver_timeout and wal_retrieve_retry_interval to something that >>> makes more sense for both physical and logical replication though. >> >> It seems to me that you should really have a different GUC, >> wal_retrieve_retry_interval has been designed to work in the startup >> process, and I think that it should still only behave as originally >> designed. > > Ah yeah I am actually confusing it with wal_receiver_timeout which > behaves same for wal_receiver and subscription worker. So yeah it makes > sense to have separate GUC
Attached two patches add new GUCs apply_worker_timeout and apply_worker_launch_interval which are used instead of wal_receiver_timeout and wal_retrieve_retry_timeout. These new parameters are not settable at worker-level so far. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
0001-Add-a-GUC-parameter-apply_worker_timeout.patch
Description: Binary data
0002-Add-a-new-GUC-parameter-apply_worker_launch_interval.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
