Re: Shared hash table allocations

On 30/03/2026 18:28, Heikki Linnakangas wrote:
> To be clear, the init_size/max_size are not completely unused at the
> moment: the lock manager sets max_size to 2 * init_size, and ...

Huh, I only now realized the implications of the above. The formula in
the lock manager is actually:

#define NLOCKENTS() \
mul_size(max_locks_per_xact, add_size(MaxBackends, max_prepared_xacts))

...
max_table_size = NLOCKENTS();
init_table_size = max_table_size / 2;

So the initial size is only half of the maximum you get from
max_locks_per_xacts * max_connections. That means that if something
consumes the "wiggle room" shared memory, you might get *fewer* locks
than you might expect based on the GUCs.

I've somehow always thought that it's the other way round, that you
might get *more* locks than max_locks_per_xacts * max_connections if
you're lucky, but that max_connections * max_locks_per_xacts was
guaranteed.

This will change with these patches.

I wonder if we should change the defaults somehow. In usual
configurations, people are currently getting much more lock space than
you'd expect based on max_connections and max_locks_per_transaction, and
after these patches, they'll get much fewer locks. It might be prudent
bump up the default max_locks_per_transaction setting so that you'd get
roughly the same amount of locks in the default configuration.

- Heikki