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
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 |