Hello, Donghang!
> One suggestion to this change is that we might need to update the amcheck doc
> to reflect that
> "This consists of a “dummy” CREATE INDEX CONCURRENTLY operation" rather than
> "CREATE INDEX" operation.
+1, done. Also fixed some typos in the commit message.
Best regards,
Mik
On Mon, Jun 02, 2025 at 05:40:18PM -0700, Donghang Lin wrote:
> Your finding is right on point! We recently used bt_index_parent_check to
> verify concurrently built indexes in a concurrent workload,
> bt_index_parent_check often gave such false positive error.
Good thing is that this is tracked i
Hi Michail
> It turns out that bt_index_parent_check is not suitable for
validating indexes built concurrently.
Your finding is right on point! We recently used bt_index_parent_check to
verify concurrently built indexes in a concurrent workload,
bt_index_parent_check often gave such false positive
Hello, Andrey!
Thanks for the review!
> I think usually write only commit year. Something tells me you can safely
write 2025 there.
Done.
> Can't wrap my head why do you need this?
Oops, copy-paste, fixed.
> I think this comment describes behavior before the fix in present tense.
Fixed.
> Snap
> On 13 Dec 2024, at 04:59, Michail Nikolaev wrote:
>
+# Copyright (c) 2021-2024, PostgreSQL Global Development Group
I think usually write only commit year. Something tells me you can safely write
2025 there.
+Test::More->builder->todo_start('filesystem bug')
+ if PostgreSQL::Test::Utils
On Mon, Dec 9, 2024 at 3:51 PM Michail Nikolaev
wrote:
> After some time, I managed to find a way to reproduce the issue. It turns out
> that bt_index_parent_check is not suitable for validating indexes built
> concurrently.
Good catch.
> I’ve attached a patch that reproduces the issue (it inc
Hello, Andrey!
> Interesting bug. It's amazing how long it stand, giving that it would be
triggered by almost any check after updating a table.
Probably because in real cases, bt_index_check is used much more frequently
than bt_index_parent_check.
> From my POV correct fix direction is to use ap
> On 9 Dec 2024, at 23:51, Michail Nikolaev wrote:
>
> * Modify bt_index_parent_check to use an MVCC snapshot for the heap scan
Hi!
Interesting bug. It's amazing how long it stand, giving that it would be
triggered by almost any check after updating a table.
From my POV correct fix directi
Hello, everyone and Peter.
I simplified the patch to reproduce the issue more effectively. Now,
bt_index_parent_check fails on a valid index containing just two tuples.
Peter, I included you in this message because you are the author of
bt_index_parent_check, so I thought you might find this rele
Hello, everyone!
While working on [0], I encountered an issue involving a missing tuple in
an index that was built concurrently. The problem only occurred once, but
it caused me a significant amount of frustration. :)
After some time, I managed to find a way to reproduce the issue. It turns
out t
10 matches
Mail list logo
