Re: use LW_SHARED in dsa_get_total_size()

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Rahila Syed <rahilasyed90(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: use LW_SHARED in dsa_get_total_size()
Date: 2025-12-02 18:41:15
Message-ID: CAA5RZ0tEtqQoohE2oTvsnrbz+hFD9zAJhAQPZGFz4SDvbNSD1w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Tue, Dec 02, 2025 at 10:31:33AM -0600, Nathan Bossart wrote:
> > 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.
>
> Here is a patch that switches to LW_SHARED in dsa_get_total_size() and
> dsa_get_total_size_from_handle().

I think this is a good idea. Exclusive here is not necessarily for the
size lookups.
A specific case I can think of is the work I have been investigating to move
pg_stat_statements query text to shared memory, concurrent backends may
need to check the size of the DSA concurrently, and this will prevent backends
from being blocked when doing so.

If it turns out a backend needs to modify the DSA, they will require
an Exclusive
lock, but that will be after the lookup.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2025-12-02 18:53:55 Re: Minor LLVM cleanups
Previous Message Andres Freund 2025-12-02 18:41:06 Re: All-visible pages with valid prune xid are confusing