On 05/04/2026 02:17, Matthias van de Meent wrote: > 0006: I don't think it is a great idea to make the LwLock machinery > the first to get allocation requests: > It has the RequestNamedLWLockTranche infrastructure, which can only > register new requests while process_shmem_requests_in_progress, and > making it request its memory ahead of everything else is likely to > cause an undersized tranche to be allocated. You could make sure that > this isn't an issue by maintaining a flag in lwlock.c that's set when > the shmem request is made (and reset on shmem exit), which must be > false when RequestNamedLWLockTranche() is called, and if not then it > should throw an error.
Good catch, RequestNamedLWLocktranche() was quite broken with the patch. I'm surprised it didn't cause test failures. We even have unit tests for that at src/test/modules/test_lwlock_tranches.
Looking at src/test/modules/test_lwlock_tranches, I realized that we don't currently check that the tranche name registered with RequestNamedLWLocktranche() is unique. If two extensions registered a tranche with same name, we'd allocate two separate tranches for them, but GetNamedLWLockTranche() would always return the first one.
Yes, while that is not very likely scenario, it’s wrong. The caller will get the wrong pointer to the locks.
Attached patches add a uniqueness check, and improves test_lwlock_tranches so that it actually uses the requested LWLocks. And I couldn't resist doing some more refactoring of the test while I was at it; IMO it's more readable now.
