Re: SIGSEGV in dynahash

Konstantin Knizhnik <knizhnik(at)garret(dot)ru> writes:
> On PG19,|ShmemInitHash|always builds afixed-sizeshared hash with abump
> allocator(|ShmemHashAlloc|) whose|alloc_arg|is astack-localregion used
> only during|hash_create|. After init, that pointer is dead.
> ...
> Pre-PG19, shared hashes used|ShmemAllocNoError|from the global pool, so
> a failed grow tended to return|NULL|/ error instead of faulting on a
> dead bump allocator.
> It was introduced by commit 9fe9ecd516b — Allocate all parts of shmem
> hash table from a single contiguous area

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.

regards, tom lane