From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Interval for launching the table sync worker |
Date: | 2017-04-06 07:15:33 |
Message-ID: | CAD21AoCrcwi3SwKKOW_efwW0finxyycLgsbw09n5uy2sxneO_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-04-06 07:17:31 | Re: Quorum commit for multiple synchronous replication. |
Previous Message | Amit Langote | 2017-04-06 07:14:13 | Re: Declarative partitioning vs. information_schema |