Re: [HACKERS] Interval for launching the table sync worker
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Interval for launching the table sync worker |
Дата | |
Msg-id | CAD21AoAVx=3ATpGBdGfvgFT1Pxka+0+NHBhJvyRJ6UdfgTSwmw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Interval for launching the table sync worker (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] Interval for launching the table sync worker
|
Список | pgsql-hackers |
On Fri, Apr 7, 2017 at 1:23 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > At Thu, 6 Apr 2017 18:42:37 +0200, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote in <8c7afb37-be73-c6bd-80bc-e87522f0461a@2ndquadrant.com> >> On 06/04/17 16:44, Masahiko Sawada wrote: >> > On Thu, Apr 6, 2017 at 9:06 PM, Kyotaro HORIGUCHI >> > <horiguchi.kyotaro@lab.ntt.co.jp> wrote: >> >>> I prefer subscription option than GUC. Something like following. >> >>> >> >>> CREATE SUBSCRIPTION s1 CONNECTION 'blah' >> >>> PUBLICATION p1 WITH (noreconnect = true); >> >>> >> >>> Stored in pg_subscription? >> >> I don't think that's a very good solution, you'd lose replication on >> every network glitch, upstream server restart, etc. > > Yes, you're right. This would work if apply worker distinguishes > permanent error. But it is overkill so far. > >> > I've added this as an open item, and sent a patch for this. >> > >> >> I am not exactly sure what's the open item from this thread. To use the >> wal_retrieve_interval to limit table sync restarts? > > It's not me. I also don't think this critical. > Thank you for the comment. It's not critical but it could be problem. So I thought we should fix it before the PostgreSQL 10 release. If it's not appropriate as an open item I'll remove it. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: