Re: [HACKERS] Interval for launching the table sync worker - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] Interval for launching the table sync worker
Date
Msg-id CAD21AoBY9UvS9QLrmaENGBGfQKOfGkGaLm=uYH24gmf-6CAoiw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Interval for launching the table sync worker  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Interval for launching the table sync worker  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: [HACKERS] Interval for launching the table sync worker  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Fri, Apr 28, 2017 at 4:00 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 4/27/17 06:47, Petr Jelinek wrote:
>> One thing I am missing in your patch however is cleanup of entries for
>> relations that finished sync. I wonder if it would be enough to just
>> destroy the hash when we get to empty list.
>
> I had omitted that because the amount of memory "leaked" is not much,
> but I guess it wouldn't hurt to clean it up.
>
> How about the attached?
>

Thank you for updating patch!

+       /*
+        * Clean up the hash table when we're done with all tables (just to
+        * release the bit of memory).
+        */
+       else if (!table_states && last_start_times)
+       {

Isn't it better to use  != NIL instead as follows?
  else if (table_state != NIL && last_start_times)


Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] Crash when partition column specified twice
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] subscription worker doesn't start immediately on eabled