On Fri, Sep 19, 2025 at 5:36 PM Matheus Alcantara
wrote:
>
> On Fri Sep 19, 2025 at 9:34 AM -03, Arseniy Mukhin wrote:
> > Hi,
> >
> Thanks for taking a look at this!
>
> > I like this approach. We got rid of dependency on clog and don't limit
> > vacuum.
ns of an
> aborted transaction are not visible to other listener backends.
>
I think it's a good test to have. FWIW there is a way to reproduce the
test condition without the injection point. We can use the fact that
serializable conflicts are checked after tx adds notifications to the
que
d of the page anymore, because we know how
many entries we can have on each page.
BTW, what do you think about creating a separate thread for the patch?
The current thread's subject seems a bit irrelevant.
Best regards,
Arseniy Mukhin
this way we will have the same order for commit records in wal and
entries in the listen/notify queue. I'm not sure what level we should
add this stuff, but it seems that to minimise the time we hold the
lock we need to release it before calling XLogFlush(). I'm not sure
about it.
Best regards,
Arseniy Mukhin
nd there is always only one writer,
so it sounds possible. And there is another option which is the patch
that Rishu Bagga is working on. In the patch all transactions write to
the listen/notify queue only after they wrote a commit record to the
WAL, so all notifications in the queue are always by committed
transactions and we don't need to call TransactionIdDidCommit.
Best regards,
Arseniy Mukhin
ations from
>
> the notify data queue.
>
If I'm not wrong, by the time we got into AtCommit_Notify we no longer
hold the global lock, so we can't provide notifications in the commit
order. I think it would work if we add entries to the position queue
concurrently with adding commit entries to the wal, as in Tom's idea
3rd step.
Another question: how to truncate notification data queue. It sounds
like it will be more difficult to figure out what data in the queue is
still needed.
Best regards,
Arseniy Mukhin
nsactions would need to perform extra work.
2) Listeners don't need to check notify transaction status, but ofc
they still need to wait if the notify transaction is 'in progress'.
3) Vacuum don't need to be listen/notify aware.
4) We don't need to do an extra scan of the whole queue.
What do you think?
Best regards,
Arseniy Mukhin
Hi!
On Sun, Aug 31, 2025 at 8:49 PM Andrey Borodin wrote:
>
> Hi!
>
> > On 31 Aug 2025, at 21:17, Arseniy Mukhin
> > wrote:
> >
> > PFA the patch that migrates BRIN vacuum to the read stream API.
>
> The patch is nice and straightforward. Looks good to m
,
Arseniy Mukhin
From fcc3ed0983151791f6d6934b7137cdcf2d839857 Mon Sep 17 00:00:00 2001
From: Arseniy Mukhin
Date: Sun, 31 Aug 2025 15:44:17 +0300
Subject: [PATCH v1] Use streaming read I/O in BRIN vacuuming
BRIN vacuum processes all index pages in physical order. Now it
uses the read stream API
On Sat, Aug 30, 2025 at 9:14 PM Andres Freund wrote:
>
> Hi,
>
> On 2025-08-30 20:33:09 +0300, Arseniy Mukhin wrote:
> > Currently, each usage of block_range_read_stream_cb is accompanied by
> > the same comment about the safety of using batchmode (there are 7
> >
block_range_read_stream_cb and drop
all duplicates. PFA the small patch that does this.
Best regards,
Arseniy Mukhin
From bf29b68997fd414d97cd784fea462366c07e40c9 Mon Sep 17 00:00:00 2001
From: Arseniy Mukhin
Date: Sat, 30 Aug 2025 20:16:47 +0300
Subject: [PATCH v1] Moves the comment about
Hi,
Thank you for looking into it!
On Tue, Aug 5, 2025 at 2:21 PM Álvaro Herrera wrote:
>
> On 2025-Jul-08, Tomas Vondra wrote:
>
> > On 7/8/25 14:40, Arseniy Mukhin wrote:
>
> > > Thank you for the feedback! I agree with the benefits. Speaking of
> > >
On Fri, Aug 1, 2025 at 11:22 PM Arseniy Mukhin
wrote:
>
> Hi,
>
> On Tue, Jul 22, 2025 at 6:43 PM Arseniy Mukhin
> wrote:
> >
> > Hi,
> >
> > While reviewing gist amcheck patch [1] I realized that brin amcheck
> > also must check if current snapsho
Hi,
On Tue, Jul 22, 2025 at 6:43 PM Arseniy Mukhin
wrote:
>
> Hi,
>
> While reviewing gist amcheck patch [1] I realized that brin amcheck
> also must check if current snapshot is OK with index indcheckxmin (as
> btree, gist do it). Currently this check is contained in btree a
am.ru#dc22ff33596f63f554cc551958131cde
Best regards,
Arseniy Mukhin
From fdb35875155d9c905901f70a7f967c2cf4bfb5e4 Mon Sep 17 00:00:00 2001
From: Arseniy Mukhin
Date: Wed, 16 Apr 2025 11:26:45 +0300
Subject: [PATCH v8 1/4] brin refactoring
For adding BRIN index support in amcheck we need some tiny chang
gist, so we need to modify it a bit. I think we can move it to
verify_common. Then we need to normalize every existing leaf index
tuple before adding it to the bloom filter. During the probing phase I
think we just can use 'gistFormTuple' to build an index tuple and then
normalize it before probing. What do you think?
Thank you!
[1]
https://www.postgresql.org/message-id/CAAhFRxiHCWe_6AmqGWZqYEkgN_uQG3Jgw0WgPw%2B0zO3_D-q4DA%40mail.gmail.com
Best regards,
Arseniy Mukhin
On Tue, Jul 8, 2025 at 4:21 PM Tomas Vondra wrote:
>
>
>
> On 7/8/25 14:40, Arseniy Mukhin wrote:
> > On Mon, Jul 7, 2025 at 3:21 PM Álvaro Herrera wrote:
> >>
> >> On 2025-Jul-07, Tomas Vondra wrote:
> >>
> >>> Alvaro, what's your
S. The
second option is to let the user define which operator to use during
the check, which, I think, makes user experience much worse in this
case. So both options look not good from the user POV as for me, so I
don't know. What do you think about it?
And should I revert the patchset to the consistent function version then?
Best regards,
Arseniy Mukhin
On Thu, Jul 3, 2025 at 10:21 PM Tom Lane wrote:
>
> Arseniy Mukhin writes:
> > Sql file is definitely more readable now. I think the patch is ready.
> > Should I move it to "Ready for Committer" status or do we need more
> > reviews or something?
>
> If yo
On Wed, Jul 2, 2025 at 8:59 PM Tom Lane wrote:
>
> Arseniy Mukhin writes:
> > Sorry, I think I wasn't clear enough. I agree with this logic, but I
> > think it implies an impossible scenario for the "equals" case. The
> > scenario where during a sca
Hi!
Here is a new version. I added a commit message. I will add it to PG19-2.
Best regards,
Arseniy Mukhin
From 0b5a1fce01dd2bb9ef43febeb497dae4eb274405 Mon Sep 17 00:00:00 2001
From: Arseniy Mukhin
Date: Wed, 2 Jul 2025 22:00:31 +0300
Subject: [PATCH v2] Add check for compressed posting list
uite a tricky part as for me,
probably it's better to add tests for this special case as it's done
for 'out of range' cases. FWIW while testing the patch I wrote some
tests for these rounding cases, I'm ready to add it to the patchset.
Thank you!
Best regards,
Arseniy Mukhin
he argument here is that it will let to do
brin check very robust (without possible false positives as in the
first approach) and easy to use (no additional parameters in the check
function). Also, the withinRange() function could be written in such a
way that it would be more efficient for our task than addValue() or
consistent().
I'd be glad to hear your thoughts!
Best regards,
Arseniy Mukhin
, maybe it is easier to
fix them by hand?)
3) It seems all geqo related file contains such comment:
-/* contributed by:
+/*
+ * contributed by:
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
* Martin Utesch * Institute of
Automatic Control *
=
Best regards,
Arseniy Mukhin
and to determine uniqueness */
2) comments where closing */ is on the last comment line. For example:
file 'crypt-blowfish.c'
before:
/* This has to be bug-compatible with the original implementation, so
* only encode 23 of the 24 bytes. :-) */
after:
/*
* This has to be bug-compatible with the original implementation, so
* only encode 23 of the 24 bytes. :-) */
Best regards,
Arseniy Mukhin
On Wed, Jun 18, 2025 at 2:39 PM Andrey Borodin wrote:
>
>
>
> > On 18 Jun 2025, at 11:33, Arseniy Mukhin
> > wrote:
> >
> > Interesting, I used btree check as reference when started
> > writing brin check, and in btree check there 53
> >
On Mon, Jun 9, 2025 at 1:16 AM Tomas Vondra wrote:
>
> On 6/8/25 14:39, Arseniy Mukhin wrote:
> > Hi,
> >
> > Here is a new version.
> >
> > TAP tests were added. Tried to reproduce more or less every violation.
> > I don't include 2 tests where
messages:
in v8-0002-amcheck-Fix-checks-of-entry-order-for-GIN-indexes.patch
- parent key is creator
- as the core incorrectly expected
and 'Arseniy Mikhin' in some patches.
Best regards,
Arseniy Mukhin
e are some thought about patches.
>
Hi Andrey! Thank you for the review.
>
> > On 10 Jun 2025, at 13:18, Arseniy Mukhin
> > wrote:
> > <0001-amcheck-Add-gin_index_check-on-a-multicolumn-index.patch>
>
> The test seems harmless and nice to have. I understand t
On Mon, Jun 9, 2025 at 7:37 PM Arseniy Mukhin
wrote:
>
> On Mon, Jun 9, 2025 at 6:34 PM Tomas Vondra wrote:
> >
> > On 6/9/25 00:14, Tomas Vondra wrote:
> > > ...
> > >
> > > I propose to split it like this, into three parts, each addressing a
&g
ill needs the commit
> message, though.
The way it splitted seems reasonable to me. Intertwined issues are
grouped together, and patches are more or less independent.
Also the test for 'posting tree parent_key check' that was added last
started failing locally. Don't know what cha
found and fixed.
Also ci compiler warnings were fixed.
Best regards,
Arseniy Mukhin
From 918cc8b07eb19f74646949cc302d6ed67f1bc920 Mon Sep 17 00:00:00 2001
From: Arseniy Mukhin
Date: Wed, 16 Apr 2025 11:26:45 +0300
Subject: [PATCH v2 1/2] brin refactoring
---
src/backend/access/brin/brin_tup
On Mon, May 26, 2025 at 7:28 PM Arseniy Mukhin
wrote:
> On Mon, May 26, 2025 at 1:27 PM Tomas Vondra wrote:
> > Also, I've noticed that the TAP test passes even with some (most) of the
> > verify_gin.c changes reverted. See the 0002 patch - this does not break
> > the
Hello Tomas,
On Mon, May 26, 2025 at 1:27 PM Tomas Vondra wrote:
>
> Hello Arseniy,
>
> I finally got time to look at this more closely, and do some testing.
Thank you for looking into this.
> Are there any cases when the current code incorrectly reports corruption
> for a valid index? So far
stack->parenttup = gin_refind_parent(rel, stack->parentblk,
stack->blkno, strategy);
I think we can remove gin_refind_parent() and do ereport right away here.
The same logic as with 3). AFAIK it's impossible to have a child item
,
Arseniy Mukhin
diff --git a/src/backend/access/gin/gininsert.c b/src/backend/access/gin/gininsert.c
index a7b7b5996e3..5643c423627 100644
--- a/src/backend/access/gin/gininsert.c
+++ b/src/backend/access/gin/gininsert.c
@@ -218,7 +218,8 @@ addItemPointersToLeafTuple(GinState *ginstate
tem.
So it seems that normally all items in additionalEntries have a
curItem larger than or equal to minItem.
It seems the correct first sentence would be:
"Normally, none of the items in additionalEntries can have a curItem
LESS than minItem"
Best regards,
Arseniy Mukhin
eviewed and more or less finalized)
3) pg_amcheck integration
Big thanks to Tomas Vondra for the first patch idea and initial review.
[1]
https://www.postgresql.org/message-id/45AC9B0A-2B45-40EE-B08F-BDCF5739D1E1%40yandex-team.ru
Best regards,
Arseniy Mukhin
From 7de60e8da824a97327a5c28ccd9d8a384
I tried Tomas's stress tests with applied patch and didn't have deadlocks.
Also there is a another way how issue can be reproduced:
apply deadlock-sleep.patch (it just adds 15 sec sleep in brin_doupdate
and few logs)
execute deadlock.sql
execute deadlock2.sql from another client (t
39 matches
Mail list logo
