Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations
Date
Msg-id aS8UZc4MqwYjoRH8@nathan
Whole thread Raw
In response to Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations  (Rahila Syed <rahilasyed90@gmail.com>)
List pgsql-hackers
On Tue, Dec 02, 2025 at 02:28:29PM +0530, Rahila Syed wrote:
> Thank you for highlighting the discussions. I'm unsure about the best
> approach here, but I think it would be safe to stay consistent with the
> rest of the code in dsa.c, especially since it's unclear that the use of
> LW_EXCLUSIVE for reading values in dsa is a mistake.

Okay.  I switched to LW_EXCLUSIVE and will consider starting a new thread
to use LW_SHARED when possible in dsa.c.

> Sorry for the confusion, I am trying to say that we can change the
> following comment
> 
> + *The area must have
> + * been created with dsa_create (not dsa_create_in_place).
> 
> to say this:
> 
> "The area must have been created using dsm_segments"
> 
> Since, this function can report the size of an area created with
> dsa_create_in_place too, as long as the area is created using
> dsm_segments.

It cannot report the size of in-place areas, at least not without some
changes, because (AFAICT) there's no way to get a dsa_handle for an
in-place segment.

I've now committed the patch.  Thanks everyone for reviewing!

-- 
nathan



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Newly created replication slot may be invalidated by checkpoint
Next
From: Nathan Bossart
Date:
Subject: use LW_SHARED in dsa_get_total_size()