Re: [HACKERS] Interval for launching the table sync worker
От | Petr Jelinek |
---|---|
Тема | Re: [HACKERS] Interval for launching the table sync worker |
Дата | |
Msg-id | bb31164a-4650-3153-8d92-ea7081c33d36@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Interval for launching the table sync worker (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: [HACKERS] Interval for launching the table sync worker
|
Список | pgsql-hackers |
On 10/04/17 11:02, Masahiko Sawada wrote: > On Sun, Apr 9, 2017 at 6:25 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> On Sat, Apr 8, 2017 at 8:13 AM, Peter Eisentraut >> <peter.eisentraut@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
В списке pgsql-hackers по дате отправления: