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