Message-ID: <9191f045-1c48-4943-8a2f-91665fc8d018@iki.fi>
Date: Thu, 20 Aug 2026 16:19:23 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: SIGSEGV in dynahash
To: Tom Lane <tgl@sss.pgh.pa.us>, Konstantin Knizhnik <knizhnik@garret.ru>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
References: <d59221f2-b3d2-41ad-8bf0-d581b42e4cba@garret.ru>
 <16448.1786810349@sss.pgh.pa.us>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <16448.1786810349@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/9191f045-1c48-4943-8a2f-91665fc8d018%40iki.fi>
Precedence: bulk

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