Thread: Re: bt_index_parent_check and concurrently build indexes

Re: bt_index_parent_check and concurrently build indexes

From
"Andrey M. Borodin"
Date:

> On 9 Dec 2024, at 23:51, Michail Nikolaev <michail.nikolaev@gmail.com> 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 direction is to use approach similar to index building.
E.i. remove "if (!state->readonly)" check. Are there any known downsides of this?


Best regards, Andrey Borodin.


Re: bt_index_parent_check and concurrently build indexes

From
"Andrey M. Borodin"
Date:

> On 13 Dec 2024, at 04:59, Michail Nikolaev <michail.nikolaev@gmail.com> wrote:
> <v3-0001-amcheck-Fix-bt_index_parent_check-behavior-with-C.patch>

+# 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::has_wal_read_bug;

Can't wrap my head why do you need this?

+# it fails, because it is expect to find the deleted row in index

I think this comment describes behavior before the fix in present tense.

-        if (snapshot != SnapshotAny)
-            UnregisterSnapshot(snapshot);

Snapshot business seems incorrect to me here...


Best regards, Andrey Borodin.