Re: Patch: fix lock contention for HASHHDR.mutex - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Patch: fix lock contention for HASHHDR.mutex
Date
Msg-id CAA4eK1JE7Vzut3JSnU2fQLeYAxr5h=V6sGB6PL2ymtG3b6BtUA@mail.gmail.com
Whole thread Raw
In response to Re: Patch: fix lock contention for HASHHDR.mutex  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: fix lock contention for HASHHDR.mutex
List pgsql-hackers
On Sat, Mar 19, 2016 at 7:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Sat, Mar 19, 2016 at 12:28 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Won't in theory, without patch as well nentries can overflow after running
> > for very long time?  I think with patch it is more prone to overflow because
> > we start borrowing from other free lists as well.
>
> Uh, I don't think so.  Without the patch, there is just one entries
> counter and it goes up and down.  How would it ever overflow?
>

I thought it can overflow because we haven't kept any upper limit on incrementing it unless the memory finishes (ofcourse that is just a theoretical assumption, as the decrements will keep the number in control), so are you thinking about the risk of overflow with patch because we have to use sum of all the nentries from all the arrays for total or is there any thing else which makes you think that changing nentries into arrays of nentries can make it prone to overflow?


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: max_parallel_degree context level
Next
From: "Shulgin, Oleksandr"
Date:
Subject: Re: unexpected result from to_tsvector