Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted
От | Tom Lane |
---|---|
Тема | Re: Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted |
Дата | |
Msg-id | 15172.1461084167@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #14098: misleading message "out of shared memory" when lock table space exhausted (John Lumby <johnlumby@hotmail.com>) |
Ответы |
Re: Re: BUG #14098: misleading message "out of shared
memory" when lock table space exhausted
|
Список | pgsql-bugs |
John Lumby <johnlumby@hotmail.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
В списке pgsql-bugs по дате отправления: