Re: Improve LWLock tranche name visibility across backends

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(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-18 22:53:44
Message-ID: CAA5RZ0viNsKqjSuJ8fo74SJrf0uMi=igOn5WrtNYmVqYVh5h-w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I've been staring at the latest patch for a bit, and I'm a bit concerned
> at how much complexity it adds.

The complexity is the fact we have to track a dsa_pointer that points
to an array of dsa_pointers that track the tranche names. We also
do have to copy the array of dsa_pointers into a new pointer when
enlarging. That adds some complexity that dshash would hide away,
but I don't think it's overly complex.

> I know we were trying to avoid using
> dshash earlier, if for no other reason than it's perhaps not the best data
> structure for the job,

yeah, we really just need an append only structure, so dshash did not
seems unnecessary. But also, we moved away from dshash before it was
decided to have a local cache. Perhaps, it's ok now to go back to dshash
considering that it will only be used in rare scenarios: creations of
new tranches and
syncs to local memory. Most of the time the tranches will be satisfied
directly from local cache.

> (or some other shmem-based
> data structure we have yet to introduce, like a dslist/dsarray).

This will be an interesting API to invest time in, if there could be more
use-cases. I think it's a separate discussion at this point.

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-08-18 23:15:06 Re: make -C src/test/isolation failure in index-killtuples due to btree_gist
Previous Message Sami Imseih 2025-08-18 22:05:00 Re: shmem_startup_hook called twice on Windows