On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen wrote:
> This comment on ProcSleep() seems to have the values of dontWait
> backward (double negatives are tricky):
>
> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
> PROC_WAIT_STATUS_ERROR
> * if not (
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
On Thu, Mar 14, 2024 at 1:15 PM Robert Haas wrote:
> Seeing no further discussion, I have committed my version of this
> patch, with your test case.
This comment on ProcSleep() seems to have the values of dontWait
backward (double negatives are tricky):
* Result: PROC_WAIT_STATUS_OK if we
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
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
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]
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
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
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
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
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
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,
I saw, thanks again!
On Wed, Jun 21, 2023 at 4:08 PM Bruce Momjian wrote:
>
> On Mon, Jun 19, 2023 at 11:32:46PM -0700, Will Mortensen wrote:
> > MERGE is now a data-modification command too.
>
> Yes, this has been applied too.
>
> --
> Bruce Momjian
MERGE is now a data-modification command too.
0002-doc-add-missing-mention-of-MERGE-in-MVCC.patch
Description: Binary data
Trivial fix to make the indentation consistent.
From 46977fbe5fa0a26ef77938a8fe30b9def062e8f8 Mon Sep 17 00:00:00 2001
From: Will Mortensen
Date: Sat, 27 Aug 2022 17:07:11 -0700
Subject: [PATCH 1/6] doc: fix markup indentation in MVCC
---
doc/src/sgml/mvcc.sgml | 16
1 file
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
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
integrate with
> the deadlock detection.
I see. What about it seems potentially unsuitable?
> On 2023-01-11 23:03:30 -0800, Will Mortensen wrote:
> > To my very limited understanding, from looking at the existing callers and
> > the implementation of LOCK, that would look so
And I don't know if there's any
reason to use a _lockmode_ other than ACCESS SHARE.
On Wed, Jan 11, 2023 at 11:03 PM Will Mortensen wrote:
>
> Hi Andres,
>
> On Wed, Jan 11, 2023 at 12:33 PM Andres Freund wrote:
> > I think such a function would still have to integrate en
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
expert on SQL syntax or typical practice for things like
this. Anything that works is fine with me. :-)
As a possibly superfluous sidebar, I wanted to correct this part of my
original message:
> On Fri, Dec 23, 2022 at 11:43 AM Will Mortensen wrote:
> > pg_sequence_last_value() (sti
Hi there,
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
Pretty trivial since this is documenting something that Postgres
*doesn't* do, but it incorrectly reversed only the bits of each
nibble, not the whole byte. See e.g.
https://www.ibm.com/docs/en/csfdcd/7.1?topic=ls-bit-ordering-in-mac-addresses
for a handy table.
diff --git
26 matches
Mail list logo
