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