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 CAMpnoC7E1FLYjCQnY-B=OnqnnvM0TfXbRO2k9iU+3OMWk=7uVQ@mail.gmail.com
Whole thread Raw
In response to Re: Exposing the lock manager's WaitForLockers() to SQL  (Will Mortensen <will@extrahop.com>)
Responses Re: Exposing the lock manager's WaitForLockers() to SQL
List pgsql-hackers
Updated patch with more tests and a first attempt at doc updates.

As the commit message and doc now point out, using
WaitForLockersMultiple() makes for a behavior difference with actually
locking multiple tables, in that the combined set of conflicting locks
is obtained only once for all tables, rather than obtaining conflicts
and locking / waiting for just the first table and then obtaining
conflicts and locking / waiting for the second table, etc. This is
definitely desirable for my use case, but maybe these kinds of
differences illustrate the potential awkwardness of extending LOCK?

Thanks again for any and all feedback!

Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: suppressing useless wakeups in logical/worker.c
Next
From: Richard Guo
Date:
Subject: Re: Incremental sort for access method with ordered scan support (amcanorderbyop)