Re: Maximum number of exclusive locks

On Tue, Sep 13, 2016 at 6:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Daniel Verite" <daniel(at)manitou-mail(dot)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.

Cheers,

Jeff