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