Re: Patch: fix lock contention for HASHHDR.mutex

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Patch: fix lock contention for HASHHDR.mutex
Дата
Msg-id CAA4eK1JE7Vzut3JSnU2fQLeYAxr5h=V6sGB6PL2ymtG3b6BtUA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Patch: fix lock contention for HASHHDR.mutex  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Patch: fix lock contention for HASHHDR.mutex  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: max_parallel_degree context level
Следующее
От: "Shulgin, Oleksandr"
Дата:
Сообщение: Re: unexpected result from to_tsvector