> On Mon, Aug 03, 2026 at 04:51:56PM -0500, Sami Imseih wrote:
> > Where this may become questionable is because there is slightly more
> > locking overhead if we go with the registry approach. The registry path goes
> > through more locking during backend startup (attaching to the
> > registry's own DSA,
> > looking up the entry, then attaching to the pgstat DSA) compared to the
> > current code which does a single dsa_attach_in_place at a known address.
> > With a high connection churn benchmark, using -C
> >
> > ```
> > pgbench -C -c $clients -T 10 -n -f bench.sql
> > ```
> >
> > 35-40 microseconds, but this is an extreme case of high connection churn.
>
> I am not troubled by these numbers myself; that's barely noticeable.
Agree.
> But I have to admit that some folks around here would likely complain
> if we change that, so I would live the optimization in place, and just
> give up on the idea. Sad, but well, I like the concept of a peaceful
> life if I can.
Also, agree. The squeeze is not worth the juice :)
> Saying that. Do you think that there could be a path forward where we
> could optimize the registry locking, benefiting everybody who uses
> this API? Just trying to think about all the sides of the coin.
I did notice a few minor optimizations while looking at this earlier. Instead of
an Exclusive lock taken unconditionaly, we can do a lookup with a
shared lwlock on DSMRegistryLock and return early, and only the
EL lwlock if we need to reigister a new DSM.
```
static void
init_dsm_registry(void)
{
...
....
/* Otherwise, use a lock to ensure only one process creates the table. */
LWLockAcquire(DSMRegistryLock, LW_EXCLUSIVE);
```
This seems like a better pattern, but with slightly more code.
Also, inside dsm_attach which gets called by init_dsm_registry(), we can
swap out LWLockAcquire(DynamicSharedMemoryControlLock, LW_EXCLUSIVE);
for a shared lock. refcnt could be an atomic.
````
dsm_segment *
dsm_attach(dsm_handle h)
{
...
.......
/* Bump reference count for this segment in shared memory. */
LWLockAcquire(DynamicSharedMemoryControlLock, LW_EXCLUSIVE);
nitems = dsm_control->nitems;
for (i = 0; i < nitems; ++i)
{
/*
* If the reference count is 0, the slot is actually unused. If the
* reference count is 1, the slot is still in use, but the segment is
* in the process of going away; even if the handle matches, another
* slot may already have started using the same handle value by
* coincidence so we have to keep searching.
*/
if (dsm_control->item[i].refcnt <= 1)
continue;
```
I will need to do some benchmarking to see if there are improvement, but
these will be optimizations for for high churn cases.
--
Sami
