On Wed, Apr 6, 2011 at 3:27 PM, Dan Ports <drkp@csail.mit.edu> wrote:
> 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.
The real fix for this problem is probably to have the ability to
actually return memory to the shared pool, rather than having everyone
grab as they need it until there's no more and never give back. But
that's not going to happen in 9.1, so the question is whether this is
a sufficiently serious problem that we ought to impose the proposed
stopgap fix between now and whenever we do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company