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
,
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
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
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
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
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
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
> >
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 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
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
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
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
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
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
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
, 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
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
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
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 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
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
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
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
25 matches
Mail list logo
