Re: Interval for launching the table sync worker

At Thu, 6 Apr 2017 16:15:33 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in <CAD21AoCrcwi3SwKKOW_efwW0finxyycLgsbw09n5uy2sxneO_A(at)mail(dot)gmail(dot)com>
> On Thu, Apr 6, 2017 at 3:45 PM, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > I was thinking the same.
> >
> > At Thu, 6 Apr 2017 11:33:22 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in <CAD21AoDCnyRJDUY=ESVVe68AukvOP2dFomTeBFpAd1TiFbjsGg(at)mail(dot)gmail(dot)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