Re: [HACKERS] Logical replication launcher uses wal_retrieve_retry_interval
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Logical replication launcher uses wal_retrieve_retry_interval |
Дата | |
Msg-id | CAD21AoC3XdcamWcZH4n7RRPgTyDWvnZ2KFNgtqRvbwXtD5Z_xg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Logical replication launcher useswal_retrieve_retry_interval (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Список | pgsql-hackers |
On Fri, Apr 14, 2017 at 9:19 PM, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: > 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. Thank you for the comment! These two parameters are classed as a standby server parameter in the document. We might want to fix it. >> 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. > It would work but IMO having multiple different behaviors for one GUC parameter is not good design. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: