From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add assertion on held AddinShmemInitLock in GetNamedLWLockTranche() |
Date: | 2023-07-28 05:37:49 |
Message-ID: | CALj2ACWcm_1NSisvatenwxo3N_z5S168-krwyzdZdt4P7z=8Fw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 28, 2023 at 8:54 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> Hi all,
>
> While digging into the LWLock code, I have noticed that
> GetNamedLWLockTranche() assumes that its caller should hold the LWLock
> AddinShmemInitLock to prevent any kind of race conditions when
> initializing shmem areas, but we don't make sure that's the case.
>
> The sole caller of GetNamedLWLockTranche() in core respects that, but
> out-of-core code may not be that careful. How about adding an
> assertion based on LWLockHeldByMeInMode() to make sure that the
> ShmemInit lock is taken when this routine is called, like in the
> attached?
+1 for asserting that the caller holds AddinShmemInitLock to prevent
reads while someone else is adding their LWLocks.
+ Assert(LWLockHeldByMeInMode(AddinShmemInitLock, LW_EXCLUSIVE));
Why to block multiple readers (if at all there exists any), with
LWLockHeldByMeInMode(..., LW_EXCLUSIVE)? I think
Assert(LWLockHeldByMe(AddinShmemInitLock)); suffices in
GetNamedLWLockTranche.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Malakhov | 2023-07-28 06:10:12 | Re: POC: Extension for adding distributed tracing - pg_tracing |
Previous Message | Bharath Rupireddy | 2023-07-28 05:17:39 | Re: Support worker_spi to execute the function dynamically. |