| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Interval for launching the table sync worker |
| Date: | 2017-04-18 16:13:26 |
| Message-ID: | CAD21AoADuEJMkSzpFfFXNkAzkaSJO7Qt5eLQzqhoJu3vpqqWhQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 18, 2017 at 11:22 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 4/13/17 06:23, Masahiko Sawada wrote:
>> Attached the latest patch. It didn't actually necessary to change
>> GetSubscriptionNotReadyRelations. I just changed the logic refreshing
>> the sync table state list.
>
> I think this was the right direction, but then I got worried about
> having a loop within a loop to copy over the last start times. If you
> have very many tables, that could be a big nested loop.
>
> Here is an alternative proposal to store the last start times in a hash
> table.
>
If we use wal_retrieve_retry_interval for the table sync worker, I
think we need to update the documentation as well. Currently the
documentation mentions that a bit, but since
wal_retrieve_retry_interval will be used at three different places for
different reason it would confuse the user.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-04-18 16:14:42 | Re: Interval for launching the table sync worker |
| Previous Message | Petr Jelinek | 2017-04-18 16:13:23 | Re: Why does logical replication launcher set application_name? |