On Fri, Apr 14, 2017 at 9:59 PM, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: > On 14/04/17 14:30, Michael Paquier wrote: >> On Fri, Apr 14, 2017 at 9:19 PM, Petr Jelinek >> <petr.jeli...@2ndquadrant.com> 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers