| 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 |
| 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 |