Re: amcheck support for BRIN indexes - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: amcheck support for BRIN indexes
Date
Msg-id 14D6E2AE-3813-4AC7-B42F-6D0E765D551C@yandex-team.ru
Whole thread Raw
In response to amcheck support for BRIN indexes  (Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>)
List pgsql-hackers

> On 18 Jun 2025, at 11:33, Arseniy Mukhin <arseniy.mukhin.dev@gmail.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
inverify_nbtree.c. 
But I recollect Peter explained this code before somewhere in pgsql-hackers. And the reasoning was something like "if
youlack a tuple in unquie constraints - it's almost certainly subsequent constrain violation and data loss". But I'm
notsure. 
And I could not find this discussion in archives.


Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Avoid possible dereference null pointer (contrib/postgres_fdw/postgres_fdw.c)
Next
From: Álvaro Herrera
Date:
Subject: Re: pg_dump misses comments on NOT NULL constraints