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
