On 10/04/17 11:02, Masahiko Sawada wrote:
> On Sun, Apr 9, 2017 at 6:25 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>> On Sat, Apr 8, 2017 at 8:13 AM, Peter Eisentraut
>> <peter.eisentr...@2ndquadrant.com> wrote:
>>> On 4/7/17 01:10, Masahiko Sawada wrote:
>>>> It's not critical but it could be problem. So I thought we should fix
>>>> it before the PostgreSQL 10 release. If it's not appropriate as an
>>>> open item I'll remove it.
>>>
>>> You wrote that you "sent" a patch, but I don't see a patch anywhere.
>>>
>>> I think a nonintrusive patch for this could be considered.
>>
>> Oops, I made a mistake. I'll send a patch tomorrow.
>>
> 
> I've attached the patch. This patch introduces GUC parameter
> table_sync_retry_interval which controls the interval of launching the
> table sync worker process.
> 

I don't think solution is quite this simple. This will cause all table
sync workers to be delayed which means concurrency will suffer and the
initial sync of all tables will take much longer especially if there is
little data. We need a way to either detect if we are launching same
worker that was already launched before, or alternatively if we are
launching crashed worker and only then apply the delay.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to