Re: Improve LWLock tranche name visibility across backends

Hi,

On Tue, Aug 12, 2025 at 04:16:48PM -0500, Sami Imseih wrote:

> I spoke offline with Bertrand and discussed the synchronization of
> the local memory from shared memory. After that discussion it is clear
> we don't need to track the highest used index in shared memory. Because
> the tranche_id comes from a shared counter, it is not possible that
> the same tranche_id can be used twice, so we will not have overlap.
> That means, when we sync, we just need to know the highest used
> index in the local memory ( since that could be populated during
> postmaster startup and inherited via fork ) and start syncing local
> memory from that point.

Thanks for the updated version!

I think that we can also get rid of max_used_index.

Indeed, I can see that it's updated when SetLocalTrancheName() is called.

But I don't think that's needed as that would be perfectly fine to restart always
from the "initial max_used_index" because that should be rare enough and the number
of entries that we scan is not large. That would mean: entry not found? resync
the entire local cache (starting again from the non updated max_used_index).

So, if we agree that we don't need to update max_used_index in
SetLocalTrancheName(), then during SyncLWLockTrancheNames() we could rely only on
DsaPointerIsValid(pointers[i]).

Indeed, those DSA pointers are only valid for dynamically registered tranches.

For example with max_used_index = 5, what you would find is DsaPointerIsValid(pointers[i])
invalid from 0 to 4 and starts to be valid at [5] (if a tranche has been dynamically
added). 5 is exactly:

"
int next_index = LWLockTrancheNames.max_used_index + 1;
"

So we could do something like:

int i = 0;
while (i < LWLockTrancheNames.shmem->allocated &&
!DsaPointerIsValid(shared_ptrs[i]))
{
i++;
}

Now this "i" acts as the "next_index" in v7 and now we can start iterating
from it and sync until it's invalid again.

That way, we get rid of max_used_index and I think that this part is simpler and
easier to understand.

Thoughts?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com