Heikki Linnakangas <heikki.linnakangas@enterprisedb.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?
There are a couple other patches which I think should be applied, if
you have time to deal with them.
There was a fix for an assertion failure here:
http://archives.postgresql.org/pgsql-bugs/2011-03/msg00352.php
It just rechecks some conditions after dropping a shared LW lock and
acquiring an exclusive LW lock. Without this recheck there is a
window for the other transaction involved in the conflict to also
detect a conflict and flag first, leading to the assertion.
There's another area I need to review near there, but that is
orthogonal.
There is a patch to improve out-of-shared-memory error handling and
reporting here:
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01170.php
This one is due to my earlier failure to spot the difference between
HASH_ENTER and HASH_ENTER_NULL. For a shared memory HTAB the
HASH_ENTER_NULL will return a null if unable to allocate the entry,
while HASH_ENTER will ereport ERROR with a generic message. This
patch leaves HASH_ENTER on the "can't happen" cases, but replaces
the ereport ERROR after it with an Assert because it's something
which should never happen. The other cases are changed to
HASH_ENTER_NULL so that the error message with the hint will be used
instead of the more generic message.
These patches are both in direct response to problems found during
testing by YAMAMOTO Takashi.
-Kevin
