On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Daniel Verite" <daniel@manitou-mail.org> writes: > Nothing to complain about, but why would the above formula > underestimate the number of object locks actually available > to a transaction? Isn't it supposed to be a hard cap for such > locks?
No, it's a minimum not a maximum. There's (intentionally) a fair amount of slop in the initial shmem size request. Once everything that's going to be allocated has been allocated during postmaster startup, the rest is available for growth of shared hash tables, which in practice means the lock table; there aren't any other shared structures that grow at runtime. So there's room for the lock table to grow a bit beyond its nominal capacity.
Having said that, the amount of slop involved is only enough for a few hundred lock entries. Not sure how you're managing to get to nearly 20000 extra entries.
The code assumes every locked object will have 2 processes that hold it (or wait for it). If you actually only have one holder for each locked object, that frees up a lot of memory to hold more locked objects.