Re: Exposing the lock manager's WaitForLockers() to SQL - Mailing list pgsql-hackers

From Will Mortensen
Subject Re: Exposing the lock manager's WaitForLockers() to SQL
Date
Msg-id CAMpnoC7miH7cGo_9xx888mWw+Xen6Drwb93TS0v9gjJxTrf4jw@mail.gmail.com
Whole thread Raw
In response to Re: Exposing the lock manager's WaitForLockers() to SQL  (Andres Freund <andres@anarazel.de>)
Responses Re: Exposing the lock manager's WaitForLockers() to SQL
List pgsql-hackers
Hi Andres,

On Thu, Jan 12, 2023 at 7:49 PM Andres Freund <andres@anarazel.de> wrote:
> Consider a scenario like this:
>
> tx 1: acquires RowExclusiveLock on tbl1 to insert rows
> tx 2: acquires AccessShareLock on tbl1
> tx 2: WaitForLockers(ShareRowExclusiveLock, tbl1) ends up waiting for tx1
> tx 1: truncate tbl1 needs an AccessExclusiveLock

Oh of course, thanks.

Is it even necessary to take the AccessShareLock? I see that one can call e.g.
RangeVarGetRelidExtended() with NoLock, and from the comments it seems
like that might be OK here?

Did you have any remaining concerns about the suitability of WaitForLockers()
for the use case?

Any thoughts on the syntax? It seems like an option to LOCK (like Marco
suggested) might be simplest to implement albeit a little tricky to document.

Supporting descendant tables looks straightforward enough (just collect more
locktags?). Views look more involved; maybe we can avoid supporting them?



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Support logical replication of DDLs
Next
From: Noah Misch
Date:
Subject: Re: allowing for control over SET ROLE