>Tom Lane > "Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
