Re: LockAcquireExtended() dontWait vs weaker lock levels than already held

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LockAcquireExtended() dontWait vs weaker lock levels than already held
Date: 2022-03-22 19:04:37
Message-ID: CA+TgmoZNbDGwXMQfn8qK3FVu4Je81nHCF3UVAmDR8rM3yUp2EQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 22, 2022 at 3:01 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> We clearly already know how to compute whether a lock is "included" in
> something we already hold - after all ProcSleep() successfully does so.
>
> Isn't it a pretty trivial test? Seems like it'd boil down to something like

I don't mind you fixing the behavior. I just couldn't pass up an
opportunity to complain about the structure of lock.c.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-03-22 19:24:57 Re: Column Filtering in Logical Replication
Previous Message Andres Freund 2022-03-22 19:04:06 Re: [PATCH] Proof of concept for GUC improvements