Re: Maximum number of exclusive locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
Cc: "pgsql-general" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Maximum number of exclusive locks
Date: 2016-09-13 13:21:04
Message-ID: 26828.1473772864@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Hu, Patricia 2016-09-13 14:20:17 Re: Predicting query runtime
Previous Message Daniel Verite 2016-09-13 12:03:28 Maximum number of exclusive locks