On 10/28/22 16:24, Peter J. Holzer wrote:
> On 2022-10-28 17:23:02 +0300, Kristjan Mustkivi wrote:
>> By the way, index rebuild while completing successfully did not fix
>> the indexes - the data in the tables was still missing even after the
>> successful rebuild command.
>
> This is surprising. As I understand it, REINDEX scans the complete table
> and builds a new index. So after a REINDEX the index should be complete
> and usable.
>
> However, reading
> https://www.postgresql.org/docs/current/sql-reindex.html I'm unsure what
> happens if you have issued a REINDEX for a table, schema, etc. and
> rebuilding an index fails: Does it abort at that time or does it just
> issue a notice and continue to rebuild the other indexes? In the latter
> case it migh be easy to miss a problem.
Debian 9 appears to be glibc 2.24 and Debian 11 is glibc 2.31. Therefore
the issue here is almost certainly corrupt indexes due to the glibc changes.
Note that some forms of the problem can manifest in primary keys or
unique indexes that were valid in the original collation behavior, but
contained duplicate rows according to the new collation. Those indexes
would not be able to be reindexed without manual intervention.
I don't know offhand what happens if you concurrently reindex an entire
database and just a few indexes fail to rebuild, but I suspect as you
mentioned above the failure might easily be missed and invalid indexes
would be left behind. I think you will find both indisready and
indisvalid false for these indexes.
HTH,
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com