YAMAMOTO Takashi wrote: > this psql session was the only activity to the server at this > point. > [no residual SIReadLock] >> Right, that's because we were using HASH_ENTER instead of >> HASH_ENTER_NULL. I've posted a patch which should correct that. > sure, with your patch it seems that they turned into different > ones. > PG_DIAG_SEVERITY: ERROR > PG_DIAG_SQLSTATE: 53200 > PG_DIAG_MESSAGE_PRIMARY: out of shared memory > PG_DIAG_MESSAGE_HINT: You might need to increase > max_pred_locks_per_transaction. > PG_DIAG_SOURCE_FILE: predicate.c > PG_DIAG_SOURCE_LINE: 2049 > PG_DIAG_SOURCE_FUNCTION: CreatePredicateLock >>> Even with the above information it may be far from clear where >>> allocations are going past their maximum, since one HTAB could >>> grab more than its share and starve another which is staying >>> below its "maximum". I'll take a look at the possibility of >>> adding a warning or some such when an HTAB expands past its >>> maximum size. >> >> I see from your later post that you are running with this patch. >> Has that reported anything yet? > > i got nothing except the following one. (in the server log) > > WARNING: hash table "ShmemIndex" has more entries than expected > DETAIL: The maximum was set to 32 on creation. That doesn't seem likely to be causing the problem, but maybe the allocations for that should be bumped a bit. These results suggest that there is some sort of a leak in the cleanup of the PredicateLockTargetHash HTAB entries. Will look into it. Thanks again. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
