Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
