From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Logical replication launcher uses wal_retrieve_retry_interval |
Date: | 2017-04-14 12:59:07 |
Message-ID: | 65799368-2ef7-3212-94d5-4fecbc11c13d@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/04/17 14:30, Michael Paquier wrote:
> On Fri, Apr 14, 2017 at 9:19 PM, Petr Jelinek
> <petr(dot)jelinek(at)2ndquadrant(dot)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 (I wonder if we then need yet another one for
tablesync though since both of those will be controlling restarts of
subscription workers after crash).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-04-14 13:02:20 | Re: Minor typo in partition.c |
Previous Message | Robert Haas | 2017-04-14 12:59:03 | Re: Small patch for pg_basebackup argument parsing |