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

From Andres Freund
Subject Re: Exposing the lock manager's WaitForLockers() to SQL
Date
Msg-id 20230111203329.jq2wvv5tlsb3hfgm@awork3.anarazel.de
Whole thread Raw
In response to Re: Exposing the lock manager's WaitForLockers() to SQL  (Marco Slot <marco.slot@gmail.com>)
Responses Re: Exposing the lock manager's WaitForLockers() to SQL
List pgsql-hackers
Hi,

On 2023-01-10 10:01:25 +0100, Marco Slot wrote:
> On Fri, Dec 23, 2022 at 11:43 AM Will Mortensen <will@extrahop.com> wrote:
> > We'd like to be able to call the lock manager's WaitForLockers() and
> > WaitForLockersMultiple() from SQL. Below I describe our use case, but
> > basically I'm wondering if this:
> >
> >     1. Seems like a reasonable thing to do
> >
> >     2. Would be of interest upstream
> >
> >     3. Should be done with a new pg_foo() function (taking an
> >        oid?), or a whole new SQL command, or something else
> 
> Definitely +1 on adding a function/syntax to wait for lockers without
> actually taking a lock.

I think such a function would still have to integrate enough with the lock
manager infrastructure to participate in the deadlock detector. Otherwise I
think you'd trivially end up with loads of deadlocks.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: logical decoding and replication of sequences, take 2
Next
From: Justin Pryzby
Date:
Subject: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode