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