Thread

Refactor PROCLOCK hash table into partitioned list allocator

Andrey Borodin <x4mmm@yandex-team.ru> — 2025-12-30T12:37:21Z

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.

This patch removes the proclock_hash() function and ProcLockHashCode() entirely, and
eliminates all hash_search() calls for PROCLOCKs. The allocation/deallocation
is now just dlist operations instead of hash table management.

Would appreciate your thoughts on this approach. Is this the direction worth working on?


Best regards, Andrey Borodin.