>>>>> "Peter" == Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
Peter> max_locks_per_transactions only affects relation locks (also
Peter> known as heavy weight locks), but pg_locks also shows other
Peter> kinds of locks.
pg_locks shows exactly two types of locks: "heavy" locks (which are not
merely relation locks but also object, tuple, extension, transaction and
advisory locks), and predicate locks (SIReadLock) which are limited by a
separate configuration parameter (and are not relevant in this case
based on the prior IRC discussion).
Peter> Filter by locktype = 'relation' to get the appropriate view.
This is incorrect (some predicate locks may be tagged 'relation' as
well, and some heavy locks will not be relation locks).
There's also the question of fastpath locks, but I believe there can
only be a small number of these (16?) per backend, so that wouldn't
account for this.
I think what's going on is that the max size of the lock hashtable isn't
strictly enforced; it'll add enough memory space for the configured
number of locks to the total size of the shared memory segment, but it
won't actually report an error until shared memory is actually
exhausted, and it's possible that there may be unused space.
(Performance may degrade if there are more locks than the configured
maximum, because the hash table will have been sized for that maximum
and can't be grown.) See comments for ShmemInitHash.
--
Andrew (irc:RhodiumToad)