Re: amcheck support for BRIN indexes
Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
From: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-19T18:32:54Z
Lists: pgsql-hackers
Attachments
- v4-0002-amcheck-brin_index_check-index-structure-check.patch (text/x-patch) patch v4-0002
- v4-0003-amcheck-brin_index_check-heap-all-consistent.patch (text/x-patch) patch v4-0003
- v4-0001-brin-refactoring.patch (text/x-patch) patch v4-0001
On Wed, Jun 18, 2025 at 2:39 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote: > > > > > 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 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