Re: Shared hash table allocations - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Shared hash table allocations
Date
Msg-id d581882f-5c34-4f8d-ac01-4f7cbd851149@iki.fi
Whole thread Raw
In response to Re: Shared hash table allocations  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Shared hash table allocations
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: AIO / read stream heuristics adjustments for index prefetching
Next
From: Daniel Gustafsson
Date:
Subject: Re: Changing the state of data checksums in a running cluster