Thread: Re: Interval for launching the table sync worker
I was thinking the same. At Thu, 6 Apr 2017 11:33:22 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoDCnyRJDUY=ESVVe68AukvOP2dFomTeBFpAd1TiFbjsGg@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? After introducing encoding conversion, untranslatable characters in a published table causes this situation. Interval can reduce the frequence of reconnecting, but I think that walreciever should refrain from reconnecting on unrecoverable(or repeating) error in walsender. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
On Thu, Apr 6, 2017 at 3:45 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > I was thinking the same. > > At Thu, 6 Apr 2017 11:33:22 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoDCnyRJDUY=ESVVe68AukvOP2dFomTeBFpAd1TiFbjsGg@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? > > 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? > 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. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
At Thu, 6 Apr 2017 16:15:33 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoCrcwi3SwKKOW_efwW0finxyycLgsbw09n5uy2sxneO_A@mail.gmail.com> > On Thu, Apr 6, 2017 at 3:45 PM, Kyotaro HORIGUCHI > <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > > I was thinking the same. > > > > At Thu, 6 Apr 2017 11:33:22 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoDCnyRJDUY=ESVVe68AukvOP2dFomTeBFpAd1TiFbjsGg@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? > > > > 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? 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. regards, -- Kyotaro Horiguchi NTT Open Source Software Center