Re: bt_index_parent_check and concurrently build indexes

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bt_index_parent_check and concurrently build indexes
Date: 2024-12-13 22:26:22
Message-ID: CAH2-WzmcFDK2OzziTgdHxPTmaRQmSFLoDjS-C06uWGTsXibx9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 9, 2024 at 3:51 PM Michail Nikolaev
<michail(dot)nikolaev(at)gmail(dot)com> 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 incorrectly reports the index as invalid, even though it is actually valid).
>
> I’m unsure of the best way to address this issue, but here are some possible options:
> * Simply update the documentation.
> * Issue a WARNING if !tupleIsAlive.
> * Modify bt_index_parent_check to use an MVCC snapshot for the heap scan

Offhand, I think that using an MVCC snapshot would make the most sense.

It's not as if there is a big benefit to not doing so with
bt_index_parent_check. My recollection is that we did it this way
because it was as close as possible to the CREATE INDEX code that
heapallindexed verification was loosely based on.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-12-13 22:41:15 Re: Hot standby queries see transient all-zeros pages
Previous Message Sergei Kornilov 2024-12-13 21:06:37 Re: Track the amount of time waiting due to cost_delay