At Thu, 06 Apr 2017 17:02:14 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20170406.170214.263553093.horiguchi.kyot...@lab.ntt.co.jp> > At Thu, 6 Apr 2017 16:15:33 +0900, Masahiko Sawada <sawada.m...@gmail.com> > wrote in <cad21aocrcwi3swkkow_efww0finxyyclgsbw09n5uy2sxne...@mail.gmail.com> > > On Thu, Apr 6, 2017 at 3:45 PM, Kyotaro HORIGUCHI > > <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > I was thinking the same. > > > > > > At Thu, 6 Apr 2017 11:33:22 +0900, Masahiko Sawada > > > <sawada.m...@gmail.com> wrote in > > > <CAD21AoDCnyRJDUY=esvve68aukvop2dfomtebfpad1tifbj...@mail.gmail.com> > > >> Hi all, > > >> > > >> While testing table sync worker for logical replication I noticed that > > >> if the table sync worker of logical replication failed to insert the > > >> data for whatever reason, the table sync worker process exits with > > >> error. And then the main apply worker launches the table sync worker > > >> again soon without interval. This routine is executed at very high > > >> frequency without interval. > > >> > > >> Should we do put a interval (wal_retrieve_interval or make a new GUC > > >> parameter?) for launching the table sync worker?
Hmm. I was playing with something wrong. Now I see the invervals 5 seconds. No problem. > > > After introducing encoding conversion, untranslatable characters > > > in a published table causes this situation. > > > > I think it's better to make a new GUC parameter for the table sync > > worker. Having multiple behaviors in wal_retrieve_retry_interval is > > not good idea. Thought? So, this is working, sorry. > I prefer subscription option than GUC. Something like following. > > CREATE SUBSCRIPTION s1 CONNECTION 'blah' > PUBLICATION p1 WITH (noreconnect = true); > > Stored in pg_subscription? > > > > Interval can reduce > > > the frequence of reconnecting, but I think that walreciever > > > should refrain from reconnecting on unrecoverable(or repeating) > > > error in walsender. > > > > > > > Yeah, that's also considerable issue. > > But not to do now. -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers