Horton

Re: Improve LWLock tranche name visibility across backends

Sami Imseih <samimseih@gmail.com>

View thread View on postgr.es
From: Sami Imseih <samimseih@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Rahila Syed <rahilasyed90@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-02T20:07:29Z
Lists: pgsql-hackers 
> I've discovered (with SQLsmith) that the new possible error makes
> pg_prewarm/autoprewarm fail when the error triggered during it's
> initialization and then another instance tries to acquire apw_state->lock.

From just a quick look at this, it does not seem to be the fault
of the error message itself, but because we no longer can
tolerate leaks in new tranche IDs. Currently the function shows:

/* XXX: this tranche is leaked */
tranche_id = LWLockNewTrancheId("test_dsa");

the test_dsa_resowners seems to not be handling
such scenarios and releasing locks, etc somewhere. If you modify
the function test_dsa_resowners and only keep the
LWLockNewTrancheId call, like this:

"
PG_FUNCTION_INFO_V1(test_dsa_resowners);
Datum
test_dsa_resowners(PG_FUNCTION_ARGS)
{
LWLockNewTrancheId("test_dsa");

PG_RETURN_VOID();
}
"
it does not repro.

Not really sure why this required "debug_parallel_query"
to be ON either, but that option itself should also be
used with caution.

I am not sure we need to do anything about this.


--
Sami Imseih
Amazon Web Services (AWS)

Commits

  1. test_dsa: Avoid leaking LWLock tranches.

  2. Teach DSM registry to ERROR if attaching to an uninitialized entry.

  3. Add a test harness for the LWLock tranche code.

  4. Revert recent change to RequestNamedLWLockTranche().

  5. Move dynamically-allocated LWLock tranche names to shared memory.

  6. Prepare DSM registry for upcoming changes to LWLock tranche names.

  7. Add GetNamedDSA() and GetNamedDSHash().