Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If you get "out of shared memory" at all due to SSI, I'd say that
> that's the problem, not exactly when it happens. I thought that
> the patch included provisions for falling back to coarser-grained
> locks whenever it was short of resources.
When one of the tests was getting out of memory errors we were
initially having trouble telling where the memory was actually
consumed, because it wasn't necessarily due to the type of object
being allocated at the point of failure. That was the motivation
for my attempt to log when an HTAB grew past its "maximum". The
problem turned out to be a field which wasn't properly initialized
in certain corner cases, making the cleanup phase fail to clear them
when appropriate. There is a patch to fix that bug, but the issue
raised in the early phase of investigation is what, if anything we
should do about the free-for-all allocation.
If we want to call that a feature and take it off the 9.1 list,
that's OK with me. It's a new issue with 9.1 in the sense that
there used to be only one HTAB which could grab the slack space, and
only generate its out of memory error once that slack space was
exhausted. Now that there are three, things are a bit less
predictable.
By the way, the problem with SSI potentially running out of shared
memory is rather parallel to how heavyweight locks can run out of
shared memory. The SLRU prevents the number of transactions from
being limited in that way, and multiple locks per table escalate
granularity, but with a strange enough workload (for example,
accessing hundreds of tables per transaction) one might need to
boost max_pred_locks_per_transaction above the default to avoid
shared memory exhaustion.
-Kevin