Re: Exposing the lock manager's WaitForLockers() to SQL

From: Andres Freund <andres(at)anarazel(dot)de>
To: Marco Slot <marco(dot)slot(at)gmail(dot)com>
Cc: Will Mortensen <will(at)extrahop(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, marco(at)citusdata(dot)com
Subject: Re: Exposing the lock manager's WaitForLockers() to SQL
Date: 2023-01-11 20:33:29
Message-ID: 20230111203329.jq2wvv5tlsb3hfgm@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)extrahop(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2023-01-11 20:38:34 Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode
Previous Message Andres Freund 2023-01-11 20:28:51 Re: logical decoding and replication of sequences, take 2