| From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | 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:40:56 |
| Message-ID: | f64d87d1-bef3-5e3e-a999-ba302816a0ee@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 18/04/17 18:14, Peter Eisentraut wrote:
> On 4/18/17 11:59, Petr Jelinek wrote:
>> Hmm if we create hashtable for this, I'd say create hashtable for the
>> whole table_states then. The reason why it's list now was that it seemed
>> unnecessary to have hashtable when it will be empty almost always but
>> there is no need to have both hashtable + list IMHO.
>
> The difference is that we blow away the list of states when the catalog
> changes, but we keep the hash table with the start times around. We
> need two things with different life times.
>
Why can't we just update the hashtable based on the catalog? I mean once
the record is not needed in the list, the table has been synced so there
is no need for the timestamp either since we'll not try to start the
worker again.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2017-04-18 16:46:22 | Re: Why does logical replication launcher set application_name? |
| Previous Message | Tom Lane | 2017-04-18 16:37:35 | Re: Why does logical replication launcher set application_name? |