4 ms·
The corruption issue is with concurrent (re)index operations, which can be done for all index types. That is, the corruption is best described as 'some table ro
by mattashii 4y ago
The corruption issue is with concurrent (re)index operations, which can be done for all index types. That is, the corruption is best described as 'some table rows may skipped when scanning the table during reindex, so the index can be incomplete', and unrelated to index methods, as any index can be reindexed concurrently.
btree is only the default index type, but otherwise unrelated, with the sole exception being that it is easy to verify whether it's corrupted - but that doesn't mean that other index methods are not affected.
Absence of evidence is not evidence of absence.
- smileysteve 4y agoBrin was implemented in a lazy fashion already. So concurrent reindexing isn't a thing
- mattashii 4y agoBRIN lazily summarizes blocks _at the end of the table_. When you build the index (by either creating or reindexing, concurrently or not) it will generate summaries for all full block ranges of the table. As such, it is possible that even a BRIN index was corrupted by concurrent reindex in PG14 < 14.4 because it didn't receive all tuples that it should have summarized.