Re: Add assertion on held AddinShmemInitLock in GetNamedLWLockTranche()

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

In response to

Responses

Browse pgsql-hackers by date

  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.