Thread

Commits

  1. Check that the tranche name is unique in RequestNamedLWLockTranche

  2. Improve test_lwlock_tranches

  1. Duplicate RequestNamedLWLocktranche() names and test_lwlock_tranches improvements

    Heikki Linnakangas <hlinnaka@iki.fi> — 2026-04-05T14:28:53Z

    Starting new thread for this thing that Matthias noticed in my 
    work-in-progress patch at 
    https://www.postgresql.org/message-id/CAEze2WjgCROMMXY0+j8FFdm3iFcr7By-+6Mwiz=PgGSEydiW3A@mail.gmail.com.
    
    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.
    
    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.
    
    Barring objections, I will commit these shortly.
    
    - Heikki
  2. Re: Duplicate RequestNamedLWLocktranche() names and test_lwlock_tranches improvements

    Sami Imseih <samimseih@gmail.com> — 2026-04-05T16:05:14Z

    > Starting new thread for this thing that Matthias noticed in my
    > work-in-progress patch at
    >
    > https://www.postgresql.org/message-id/CAEze2WjgCROMMXY0+j8FFdm3iFcr7By-+6Mwiz=PgGSEydiW3A@mail.gmail.com
    > .
    >
    > 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.
    >
    > Barring objections, I will commit these shortly.
    >
    
    LGTM
    
    --
    Sami Imseih
    Amazon Web Services (AWS)
    
  3. Re: Duplicate RequestNamedLWLocktranche() names and test_lwlock_tranches improvements

    Heikki Linnakangas <hlinnaka@iki.fi> — 2026-04-05T18:24:35Z

    On 05/04/2026 19:05, Sami Imseih wrote:
    > LGTM
    
    Committed, thanks!
    
    - Heikki