Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Rahila Syed <rahilasyed90(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations
Date: 2025-12-02 16:31:33
Message-ID: aS8UZc4MqwYjoRH8@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-12-02 17:17:39 use LW_SHARED in dsa_get_total_size()
Previous Message Masahiko Sawada 2025-12-02 16:26:18 Re: Newly created replication slot may be invalidated by checkpoint