Re: Improve LWLock tranche name visibility across backends

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve LWLock tranche name visibility across backends
Date: 2025-08-16 17:18:38
Message-ID: CAA5RZ0tm6UFuY43-=fB-JtDEten3gA6tMCH1zLv+R9FT=MDApg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> So we could do something like:
>
> int i = 0;
> while (i < LWLockTrancheNames.shmem->allocated &&
> !DsaPointerIsValid(shared_ptrs[i]))
> {
> i++;
> }

I found a different approach without tracking an additional counter.
Then sync stops when an invalid pointer is found after at least
one valid entry in shared memory, so we don't stop if there was a
lwlock registered in local memory during postmaster startup, and
this tranche will never actually be added to shared memory at
the same position.

>> Is there any reason to continue allowing this? For example, maybe we could
>> ERROR if LWLockInitialize()/GetLWTrancheName() are given a tranche_id
>> greater than the number allocated. I guess I'm not following why we should
>> gracefully handle these kinds of coding errors, especially when they result
>> in unhelpful behavior like an "extension" tranche.

> Essentially, we can call GetLWTrancheName within LWLockInitialize, but
> GetLWTrancheName can no longer have a fallback value such as "extension".
> It should error out instead. I believe that is what you mean. correct?

I also added this, so now only LWLocks correctly registered can be looked
up.

I also reconsidered the use of INJECTION_POINT for this purpose.
I felt it added unnecessary code where we only need a DEBUG ( I used DEBUG3)
statement at a few key places.

See v7.

--
Sami

Attachment Content-Type Size
v7-0002-Add-tests-for-LWLock-tranche-names-DSA.patch application/octet-stream 18.2 KB
v7-0001-Implement-a-DSA-for-LWLock-tranche-names.patch application/octet-stream 32.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-08-16 17:29:31 Re: About Custom Aggregates, C Extensions and Memory
Previous Message Marthin Laubscher 2025-08-16 16:04:59 Re: About Custom Aggregates, C Extensions and Memory