Re: [HACKERS] Interval for launching the table sync worker
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] Interval for launching the table sync worker |
Дата | |
Msg-id | CAD21AoD-Zmz29omx9m4LUh7+cM6Sreg-Vqc3ZH5nA0vGs6NeeQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Interval for launching the table sync worker (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Interval for launching the table sync worker
|
Список | pgsql-hackers |
On Wed, Apr 12, 2017 at 1:28 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 4/10/17 08:10, Petr Jelinek wrote: >> 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. > > Perhaps instead of a global last_start_time, we store a per relation > last_start_time in SubscriptionRelState? I was thinking the same. But a problem is that the list of SubscriptionRelState is refreshed whenever the syncing table state becomes invalid (table_state_valid = false). I guess we need to improve these logic including GetSubscriptionNotReadyRelations(). Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: