Re: amcheck support for BRIN indexes

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: amcheck support for BRIN indexes
Date: 2025-06-18 11:39:05
Message-ID: 14D6E2AE-3813-4AC7-B42F-6D0E765D551C@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 18 Jun 2025, at 11:33, Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com> wrote:
>
> Interesting, I used btree check as reference when started
> writing brin check, and in btree check there 53
> ERRCODE_INDEX_CORRUPTED ereports and only 1 ERRCODE_DATA_CORRUPTED
> ereport. So it was very hard to do, but I managed to pick the wrong
> one. I wonder if this btree check ereport should also be changed to
> ERRCODE_INDEX_CORRUPTED?

It's there in a case of heapallindexes failure. I concur that ERRCODE_INDEX_CORRUPTED is more appropriate in that case in verify_nbtree.c.
But I recollect Peter explained this code before somewhere in pgsql-hackers. And the reasoning was something like "if you lack a tuple in unquie constraints - it's almost certainly subsequent constrain violation and data loss". But I'm not sure.
And I could not find this discussion in archives.

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-06-18 14:35:54 Re: pg_dump misses comments on NOT NULL constraints
Previous Message Ranier Vilela 2025-06-18 11:33:49 Re: Avoid possible dereference null pointer (contrib/postgres_fdw/postgres_fdw.c)