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  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Interval for launching the table sync worker
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] TAP tests take a long time