Re: SIGSEGV in dynahash

On 15/08/2026 19:12, Tom Lane wrote:
> Yeah. I'm not too pleased with 9fe9ecd516b for a different reason.
>
> In pursuit of what seems to be a merely cosmetic goal (ie make shared
> hashes be reported differently in pg_shmem_allocations), it's made a
> fundamental and IMO possibly destabilizing change in the behavior of
> shared-memory hash tables. To wit, it is no longer possible to expand
> a shared hash table beyond its startup-time allocation. For some of
> them that doesn't matter, but for others it definitely does; the lock
> table in particular is sized only heuristically. For the last couple
> of decades, there was slop in the max_locks_per_transaction limit
> because the lock table could grow into the 100kB slop space we leave
> in shared memory; but now there is no slop. I suspect we will get
> complaints from people whose workloads used to work without trouble
> and now don't. There might be extension code that depends on shared
> hashtables not having a hard limit, too.
>
> I wonder whether we shouldn't just revert this.

This was discussed at the time. My opinion, and I thought there was a
consensus on it, is that the unpredictable behavior of the "slop" was
not a good idea. The slop got assigned to whatever hash table happened
to use it first, and from there on it was reserved for that hash table
until server restart. That's pretty unpredictable, and hard to reason
about for tuning purposes.

It was all about the lock manager, none of the other hash tables used
the slop. The lock table consists of two hash tables, the "LOCK hash"
and the "PROCLOCK hash". The slop would get assigned to one of those
depending on the kind of queries you run after server startup. If you
ran a query that happened to need a lot of "LOCK hash" space, and then
ran a workload that needed more "PROCLOCK hash" space, the latter would
fail. But if you ran the queries in different order, then the slop was
assigned to the "PROLOCK hash" and it would work, but running the other
kind of query would fail instead. Weird.

I increased the default for max_locks_per_transaction (commit
79534f9065) to compensate for this, so that most applications that were
using the default settings and were relying on the slop will continue to
work.

- Heikki