Re: amcheck support for BRIN indexes

On Wed, Jun 18, 2025 at 2:39 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
>
>
> > 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.
>

There is a thread about heapallindexed feature [1], I guess this is a
one you mentioned? Also it turned out that this error code is
explained in the code comment:

* Since the overall structure of the index has already been verified, the most
* likely explanation for error here is a corrupt heap page (could be logical
* or physical corruption). ...

Now I wonder if we need to use ERRCODE_DATA_CORRUPTED in the 'heap all
consistent' part? It's similar to btree heapallindexed check. We have
a structurally consistent index, but for some reason it is not
consistent with the heap. It seems to me it's impossible to say who we
should blame here. I leave ERRCODE_INDEX_CORRUPTED for now.

I noticed that fixes about year and error codes didn't get to the last
version for some reason, so there is a new version with fixes. Also I
changed the 'heap all consistent' error message "Index %s is
corrupted" -> "Index %s is not consistent with the heap". New message
looks less misleading as we don't know where the problem is. Thanks!

[1] https://www.postgresql.org/message-id/CAH2-WzmVKiwcNrhYFH9CTLLcmQTMH_xjW%3DAvxfDKAftmY47QKw%40mail.gmail.com

Best regards,
Arseniy Mukhin