From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Lumby <johnlumby(at)hotmail(dot)com> |
Cc: | pgsql bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted |
Date: | 2016-04-19 16:42:47 |
Message-ID: | 15172.1461084167@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
John Lumby <johnlumby(at)hotmail(dot)com> writes:
> Firstly, the documentation (Server Configuration, Lock Management) is very clear :
> _____________________________________________________
> max_locks_per_transaction (integer)
> The shared lock table tracks locks on
> max_locks_per_transaction * (max_connections + max_prepared_transactions) objects (e.g., tables);
> hence, *no more* than this many distinct objects can be locked at any one time.
You're mistaking a guarantee for a hard limit.
What actually happens is that enough shared memory is reserved for at
least max_locks_per_transaction * (max_connections +
max_prepared_transactions) lock entries, plus a bunch of unrelated stuff,
plus some slop. The other uses of shared memory are pretty static, so the
end result is that only the lock table is likely to eat up the slop.
max_locks_per_transaction is thus more of a floor than a ceiling.
I'm not sure if that documentation wording needs improvement or not.
Other references to max_locks_per_transaction don't seem to imply that
it's an exact bright line, but I can see where if you read only that
line in this para and not the rest of the para, you might come away
with such a conclusion.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Lumby | 2016-04-19 17:36:35 | Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted |
Previous Message | John Lumby | 2016-04-19 14:45:11 | Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted |