From: Tom Lane <tgl@sss.pgh.pa.us>
To: Konstantin Knizhnik <knizhnik@garret.ru>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: SIGSEGV in dynahash
In-reply-to: <d59221f2-b3d2-41ad-8bf0-d581b42e4cba@garret.ru>
References: <d59221f2-b3d2-41ad-8bf0-d581b42e4cba@garret.ru>
Comments: In-reply-to Konstantin Knizhnik <knizhnik@garret.ru>
	message dated "Sat, 15 Aug 2026 16:06:53 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <16447.1786810349.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sat, 15 Aug 2026 12:12:29 -0400
Message-ID: <16448.1786810349@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/16448.1786810349%40sss.pgh.pa.us>
Precedence: bulk

Konstantin Knizhnik <knizhnik@garret.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