| From: | Will Mortensen <will(at)extrahop(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Marco Slot <marco(dot)slot(at)gmail(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-07-04 08:11:05 |
| Message-ID: | CAMpnoC7E1FLYjCQnY-B=OnqnnvM0TfXbRO2k9iU+3OMWk=7uVQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| v2-0001-Add-WAIT-ONLY-option-to-LOCK-statement.patch | application/octet-stream | 29.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2023-07-04 08:12:39 | Re: Incremental sort for access method with ordered scan support (amcanorderbyop) |
| Previous Message | Daniel Gustafsson | 2023-07-04 07:48:23 | Re: suppressing useless wakeups in logical/worker.c |