Re: Shared hash table allocations
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Shared hash table allocations |
| Дата | |
| Msg-id | d581882f-5c34-4f8d-ac01-4f7cbd851149@iki.fi обсуждение |
| Ответ на | Re: Shared hash table allocations (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
| Ответы |
Re: Shared hash table allocations
|
| Список | pgsql-hackers |
On 03/04/2026 16:03, Ashutosh Bapat wrote: > On Thu, Apr 2, 2026 at 10:15 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote: >>> I think the release notes should "nudge" all the >>> users who use non-default max_locks_per_transaction to increase it if >>> they see "out of memory" errors. I don't think it should provide a >>> blanket advise to double their locks >> >> How about: >> >> "If you had previously set max_locks_per_transaction, you might need to >> set it to a higher value in v19 to avoid "out of shared memory" errors. >> If you are unsure what to set it to and don't mind the increased memory >> usage, you can double the value to ensure that you can acquire at least >> as many locks as before" > > The wiggle room is 100KB fixed + 10% of other two structures, so value > by which it should be increased is partly fixed and partly a multiple > of current value. "double the value" is simplest advice we can give. > +1. Ok, committed these patches to remove the safety margins, make LOCK and PROCLOCK fixed-size, and change the default to max_locks_per_transaction=128. I will do one final self-review of the remaining earlier patches from this thread next; I believe they're ready to be committed too. Thanks for the review! - Heikki
В списке pgsql-hackers по дате отправления: