On Thu, May 30, 2024 at 12:01 AM Will Mortensen wrote:
> FWIW, another solution might be to directly expose the functions that
> WaitForLockers() calls, namely GetLockConflicts() (generalized to
> GetLockers() in the first patch) to identify the transactions holding
> the locks, and VirtualXactLoc
I should add that the latest patches remove permissions checks because
pg_locks doesn't have any, and improve the commit messages. Hope I
didn't garble anything doing this late after the dev conference. :-)
Robert asked me about other existing functions that could be
leveraged, such as GetConflict
I got some very helpful off-list feedback from Robert Haas that this
needed more self-contained explanation/motivation. So here goes. :-)
This patch set adds a new SQL function pg_wait_for_lockers(), which
waits for transactions holding specified table locks to commit or roll
back. This can be use
Rebased, fixed a couple typos, and reordered the isolation tests to
put the most elaborate pair last.
v11-0001-Refactor-GetLockConflicts-into-more-general-GetL.patch
Description: Binary data
v11-0002-Allow-specifying-single-lockmode-in-WaitForLocke.patch
Description: Binary data
v11-0003-Add-
Rebased and fixed conflicts.
FWIW re: Andrey's comment in his excellent CF summary email[0]: we're
currently using vanilla Postgres (via Gentoo) on single nodes, and not
anything fancy like Citus. The Citus relationship is just that we were
inspired by Marco's blog post there. We have a variety of
Minor style fix; sorry for the spam.
v9-0001-Refactor-GetLockConflicts-into-more-general-GetLo.patch
Description: Binary data
v9-0002-Allow-specifying-single-lockmode-in-WaitForLocker.patch
Description: Binary data
v9-0003-Add-pg_wait_for_lockers-function.patch
Description: Binary data
I guess the output of the deadlock test was unstable, so I simply
removed it in v8 here, but I can try to fix it instead if it seems
important to test that.
v8-0001-Refactor-GetLockConflicts-into-more-general-GetLo.patch
Description: Binary data
v8-0003-Add-pg_wait_for_lockers-function.patch
De
On Fri, Jan 26, 2024 at 4:54 AM vignesh C wrote:
>
> CFBot shows that there is one warning as in [1]:
> patching file doc/src/sgml/libpq.sgml
> ...
> [09:30:40.000] [943/2212] Compiling C object
> src/backend/postgres_lib.a.p/storage_lmgr_lock.c.obj
> [09:30:40.000] c:\cirrus\src\backend\storage\l
On Thu, 11 Jan 2024 at 15:22, Will Mortensen wrote:
>
> Here is a new series adding a single pg_wait_for_lockers() function
> that takes a boolean argument to control the interpretation of the
> lock mode. It omits LOCK's handling of descendant tables so it
> requires permissions directly on desce
Here is a new series adding a single pg_wait_for_lockers() function
that takes a boolean argument to control the interpretation of the
lock mode. It omits LOCK's handling of descendant tables so it
requires permissions directly on descendants in order to wait for
locks on them. Not sure if that wou
Hi Laurenz, thanks for taking a look!
On Sat, Jan 6, 2024 at 4:00 AM Laurenz Albe wrote:
> While your original use case is valid, I cannot think of
> any other use case. So it is a special-purpose statement that is only
> useful for certain processing of append-only tables.
It is definitely som
On Sat, 2024-01-06 at 02:57 -0800, Will Mortensen wrote:
> Simplified the code and docs, and rewrote the example with more prose
> instead of PL/pgSQL, which unfortunately made it longer, although it
> could be truncated. Not really sure what's best...
I thought about this idea, and I have some do
Simplified the code and docs, and rewrote the example with more prose
instead of PL/pgSQL, which unfortunately made it longer, although it
could be truncated. Not really sure what's best...
v5-0001-Refactor-GetLockConflicts-into-more-general-GetLo.patch
Description: Binary data
v5-0003-Add-WAIT
I meant to add that the example in the doc is adapted from Marco
Slot's blog post linked earlier:
https://www.citusdata.com/blog/2018/06/14/scalable-incremental-data-aggregation/
On Sun, Sep 3, 2023 at 11:16 PM Will Mortensen wrote:
> I realized that for our use case, we'd ideally wait for holders of
> RowExclusiveLock only, and not e.g. VACUUM holding
> ShareUpdateExclusiveLock. Waiting for lockers in a specific mode seems
> possible by generalizing/duplicating WaitForLoc
I realized that for our use case, we'd ideally wait for holders of
RowExclusiveLock only, and not e.g. VACUUM holding
ShareUpdateExclusiveLock. Waiting for lockers in a specific mode seems
possible by generalizing/duplicating WaitForLockersMultiple() and
GetLockConflicts(), but I'd love to have a s
Updated docs a bit. I'll see about adding this to the next CF in hopes
of attracting a reviewer. :-)
v3-0001-Add-WAIT-ONLY-option-to-LOCK-command.patch
Description: Binary data
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, r
Here is a first attempt at a WIP patch. Sorry about the MIME type.
It doesn't take any locks on the tables, but I'm not super confident
that that's safe, so any input would be appreciated.
I omitted view support for simplicity, but if that seems like a
requirement I'll see about adding it. I assu
Hi Andres,
On Thu, Jan 12, 2023 at 7:49 PM Andres Freund wrote:
> Consider a scenario like this:
>
> tx 1: acquires RowExclusiveLock on tbl1 to insert rows
> tx 2: acquires AccessShareLock on tbl1
> tx 2: WaitForLockers(ShareRowExclusiveLock, tbl1) ends up waiting for tx1
> tx 1: truncate tbl1 ne
Hi,
On 2023-01-12 19:21:00 -0800, Will Mortensen wrote:
> FWIW re: deadlocks in general, I probably didn't highlight it well in my
> original email, but the existing solution for this use case (as Marco
> described in his blog post) is to actually lock the table momentarily.
> Marco's blog post us
Hi Andres,
On Thu, Jan 12, 2023 at 11:31 AM Andres Freund wrote:
> I know that WaitForLockers() is an existing function :). I'm not sure it's
> entirely suitable for your use case. So I mainly wanted to point out that if
> you end up writing a separate version of it, you still need to integrate w
Hi,
On 2023-01-11 23:03:30 -0800, Will Mortensen wrote:
> On Wed, Jan 11, 2023 at 12:33 PM Andres Freund wrote:
> > 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
I suppose if it's correct that we need to lock the table first (at least
in ACCESS SHARE mode), an option to LOCK perhaps makes
more sense. Maybe you could specify two modes like:
LOCK TABLE IN _lockmode_ MODE AND THEN WAIT FOR CONFLICTS WITH _waitmode_ MODE;
But that might be excessive. :-D And
Hi Andres,
On Wed, Jan 11, 2023 at 12:33 PM Andres Freund wrote:
> 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.
Could you elaborate
Hi,
On 2023-01-10 10:01:25 +0100, Marco Slot wrote:
> On Fri, Dec 23, 2022 at 11:43 AM Will Mortensen 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:
> >
Hi Marco, thanks for the reply! Glad to know you'd find it useful too. :-)
On Tue, Jan 10, 2023 at 1:01 AM Marco Slot wrote:
> I'm wondering whether it could be an option of the LOCK command.
> (LOCK WAIT ONLY?)
I assume that's doable, but just from looking at the docs, it might be
a little conf
On Fri, Dec 23, 2022 at 11:43 AM Will Mortensen 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 b
28 matches
Mail list logo
