From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
---|---|
To: | 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:19:09 |
Message-ID: | fa3898f4-667a-f131-e49a-75d7b3e4a3c1@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/04/17 12:57, Masahiko Sawada wrote:
> Hi,
>
> I noticed that the logical replication launcher uses
> wal_retrieve_retry_interval as a interval of launching logical
> replication worker process. This behavior is not documented and I
> guess this is no longer consistent with what its name means.
>
Yes that was done based on reviews (and based on general attitude of not
adding more knobs that are similar in meaning). It is briefly documented
in the replication config section. Same is true for wal_receiver_timeout
btw.
> I think that we should either introduce a new GUC parameter (say
> logical_replication_retry_interval?) for this or update the
> description of wal_retrieve_retry_interval. IMO the former is better.
>
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.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-04-14 12:22:33 | Re: Rewriting the test of pg_upgrade as a TAP test |
Previous Message | Petr Jelinek | 2017-04-14 12:14:13 | Re: Interval for launching the table sync worker |