agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: Tom Lane <tgl@sss.pgh.pa.us>
To: Konstantin Knizhnik <knizhnik@garret.ru>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: SIGSEGV in dynahash
Date: Sat, 15 Aug 2026 12:12:29 -0400
Message-ID: <16448.1786810349@sss.pgh.pa.us> (raw)
In-Reply-To: <d59221f2-b3d2-41ad-8bf0-d581b42e4cba@garret.ru>
References: <d59221f2-b3d2-41ad-8bf0-d581b42e4cba@garret.ru>
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
view thread (6+ messages) latest in thread
Message-ID: <16448.1786810349@sss.pgh.pa.us>
Permalink: ../16448.1786810349@sss.pgh.pa.us/
Also on: postgresql.org/message-id/16448.1786810349@sss.pgh.pa.us
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, knizhnik@garret.ru, hlinnaka@iki.fi, pgsql-bugs@lists.postgresql.org
Subject: Re: SIGSEGV in dynahash
In-Reply-To: <16448.1786810349@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox