Re: [HACKERS] Interval for launching the table sync worker
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: [HACKERS] Interval for launching the table sync worker |
Дата | |
Msg-id | 20170407.132353.137213222.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Interval for launching the table sync worker (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Interval for launching the table sync worker
|
Список | pgsql-hackers |
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. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: