Re: bt_index_parent_check and concurrently build indexes

Andrey Borodin <x4mmm@yandex-team.ru>

From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>

To: Michail Nikolaev <michail.nikolaev@gmail.com>

Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2024-12-15T17:41:37Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

amcheck: Fix snapshot usage in bt_index_parent_check
- e1a327dc4dcb 17.8 landed
- dcddd6987197 15.16 landed
- 607a67c5e657 14.21 landed
- 3c83a2a0ace9 18.2 landed
- 1f28982e4094 19 (unreleased) landed
- 098a1fab8a9b 16.12 landed
- df93f94dda51 18.2 landed
- ce2f575b7cf4 17.8 landed
- 6bd469d26aca 19 (unreleased) landed
Teach contrib/amcheck to check the unique constraint violation
- 5ae2087202af 17.0 cited

> 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.