From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Dan Ports <drkp(at)csail(dot)mit(dot)edu>, YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSI bug? |
Date: | 2011-04-11 10:58:40 |
Message-ID: | 4DA2DEE0.50801@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11.04.2011 11:33, Heikki Linnakangas wrote:
> On 31.03.2011 22:06, Kevin Grittner wrote:
>> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>
>>> That's not enough. The hash tables can grow beyond the maximum
>>> size you specify in ShmemInitHash. It's just a hint to size the
>>> directory within the hash table.
>>>
>>> We'll need to teach dynahash not to allocate any more entries
>>> after the preallocation. A new HASH_NO_GROW flag to hash_create()
>>> seems like a suitable interface.
>>
>> OK. If we're doing that, is it worth taking a look at the "safety
>> margin" added to the size calculations, and try to make the
>> calculations more accurate?
>>
>> Would you like me to code a patch for this?
>
> I finally got around to look at this. Attached patch adds a
> HASH_FIXED_SIZE flag, which disables the allocation of new entries after
> the initial allocation. I believe we have consensus to make the
> predicate lock hash tables fixed-size, so that there's no competition of
> the slack shmem space between predicate lock structures and the regular
> lock maanager.
Ok, committed that.
I left the safety margins in the size calculations alone for now.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-04-11 11:01:22 | Re: SSI bug? |
Previous Message | Leonardo Francalanci | 2011-04-11 10:41:18 | Re: switch UNLOGGED to LOGGED |