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-10T12:56:06Z

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