Message-ID: <3d7e7d38-b3c1-4adf-8cb0-309dba08dba9@iki.fi>
Date: Tue, 6 Jan 2026 16:23:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Refactor PROCLOCK hash table into partitioned list allocator
To: Andrey Borodin <x4mmm@yandex-team.ru>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <271502B5-C950-4428-AF69-9C6D62EF5F14@yandex-team.ru>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <271502B5-C950-4428-AF69-9C6D62EF5F14@yandex-team.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/3d7e7d38-b3c1-4adf-8cb0-309dba08dba9%40iki.fi>
Precedence: bulk

On 30/12/2025 14:37, Andrey Borodin wrote:
> Hi hackers,
> 
> Following up on the Discord discussion about the PROCLOCK hash table being
> a "weird allocator" that we never actually use for lookups - I took a stab at
> replacing it with a simpler partitioned free list approach as was suggested.
> I was doing this mostly to educate myself on Lock Manager internals.
> 
> The current implementation uses LockMethodProcLockHash purely as an allocator.
> We never do hash lookups by key; we only allocate entries, link them to the lock's
> procLocks list, and free them later. Using a full hash table for this adds
> unnecessary complexity and maybe even overhead (I did not measure this).
> 
> The attached patch replaces this with:
> - ProcLockArray: A fixed-size array of all PROCLOCK structs (allocated at startup)
> - ProcLockFreeList: Partitioned free lists, one per lock partition to reduce contention
> - ProcLockAlloc/Free: Simple push/pop operations on the free lists
> - PROCLOCK lookup: Linear traversal of lock->procLocks (see LockRefindAndRelease()
>    and FastPathGetRelationLockEntry())
> 
> The last point bothers me most. It seems like this traversals are expected to be short.
> But I'm not 100% sure.

Hmm, yeah the last point contradicts the premise that the hash table is 
used purely as an allocator. It *is* used for lookups, and you're 
replacing them with linear scans. That doesn't seem like an improvement.

- Heikki