Re: SSI bug?

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

In response to

  • Re: SSI bug? at 2011-04-11 08:33:06 from Heikki Linnakangas

Browse pgsql-hackers by date

  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