Re: bt_index_parent_check and concurrently build indexes

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>

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

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

Date: 2024-12-13T22:26:22Z

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 Mon, Dec 9, 2024 at 3:51 PM Michail Nikolaev
<michail.nikolaev@gmail.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