Clean up NamedLWLockTranche stuff

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Clean up NamedLWLockTranche stuff
Date: 2026-03-26 12:16:52
Message-ID: 47aaf57e-1b7b-4e12-bda2-0316081ff50e@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While working on the new shmem allocation functions, I looked at how the
NamedLWLockTranche stuff works now in lwlock.c, and I have to say it's a
bit of a mess.

What is a "named tranche"? It usually means tranches requested with
RequestNamedLWLockTranche() at postmaster startup. But all tranches have
a name. LWLockTrancheNames includes all user-defined tranches, also ones
assigned with LWLockNewTrancheId(), and MAX_NAMED_TRANCHES is the
maximum for all of them.

At postmaster startup, NamedLWLockTrancheRequests points to a
backend-private array. But after startup, and always in backends, it
points to a copy in shared memory and
LocalNamedLWLockTrancheRequestArray is used to hold the original. It
took me a while to realize that NamedLWLockTrancheRequests in shared
memory is *not* updated when you call LWLockNewTrancheId(), it only
holds the requests made with RequestNamedLWLockTranche() before startup.

I propose the attached refactorings to make this less confusing. See
commit messages for details.

- Heikki

Attachment Content-Type Size
v1-0001-Rename-MAX_NAMED_TRANCHES-to-MAX_USER_DEFINED_TRA.patch text/x-patch 3.0 KB
v1-0002-Refactor-how-user-defined-LWLock-tranches-are-sto.patch text/x-patch 21.1 KB
v1-0003-Use-a-separate-spinlock-to-protect-LWLockTranches.patch text/x-patch 5.5 KB
v1-0004-Use-ShmemInitStruct-to-allocate-lwlock.c-s-shared.patch text/x-patch 7.5 KB
v1-0005-Move-ShmemIndexLock-into-ShmemAllocator.patch text/x-patch 6.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-03-26 12:37:19 Re: pg_publication_tables: return NULL attnames when no column list is specified
Previous Message Fujii Masao 2026-03-26 11:56:35 Re: pg_stat_replication.*_lag sometimes shows NULL during active replication