Re: shared memory release following failed lock acquirement.

>Tom Lane
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > Does this mean that the parameter max_locks_per_transaction
> isn't honoured
> > at all, it is just used to size the lock table
>
> Yes, and that's how it's documented.
>

The name max_locks_per_transaction indicates a limit of some kind. The
documentation doesn't mention anything about whether that limit is enforced
or not.

I suggest the additional wording:
"This parameter is not a hard limit: No limit is enforced on the number of
locks in each transaction. System-wide, the total number of locks is limited
by the size of the lock table."

The recent patch stops the system from crashing with an out of memory
condition, though this probably slightly hastens the condition of "no locks"
available. It would be good to clarify what behaviour the system exhibits
when we run out of locks.

I'm not sure myself now what that behaviour is: My understanding is that we
do not perform lock escalation (as does DB2), so presumably we just grind to
a halt? I take it that there is no automated way of getting out of this
situation? i.e. the deadlock detector doesn't start killing transactions
that hold lots of locks to free up space? So, we would basically just start
to build up lots of people waiting on locks - though without any mechanism
for diagnosing this is happening? What does happen and where does it end
(now)?

Best Regards, Simon Riggs