On Wed, Apr 06, 2011 at 12:25:26PM -0500, Kevin Grittner wrote:
> 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.
In fact, it's exactly the same: if a backend wants to acquire many
heavyweight locks, it doesn't stop at max_locks_per_xact, it just
keeps allocating them until shmem is exhausted.
So it's possible, if less likely, to have the same problem with regular
locks causing the system to run out of shared memory. Which sounds to
me like a good reason to address both problems in one place.
Dan
--
Dan R. K. Ports MIT CSAIL http://drkp.net/
