Postgres pg_upgrade 损坏的索引（英国）缺少值，尽管基于索引的选择缺少记录

Question

在 9.6->12.3 pg_upgrade 之后，我们标记了一些严重的选择，给出了缺失的结果！ REINDEX 或 drop / create 解决了问题。

升级要点

1. 停止 9.6
2. rsync 9.6 数据和 bin 文件从 Centos7 到 Centos8（预装12）
3. pg_upgrade
4. ./analyze_new_cluster.sh
5. ./delete_old_cluster.sh

每个数据库我们发现 1-3 个唯一损坏的索引。每个索引缺少大约 20 个值。

我们发现了一个非常有用的工具 amcheck！ https://www.postgresql.org/docs/10/amcheck.html

SELECT bt_index_check(c.oid), c.relname, c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree' AND n.nspname = 'pg_catalog'
-- Don't check temp tables, which may be from another session:
AND c.relpersistence != 't'
-- Function may throw an error when this is omitted:
AND i.indisready AND i.indisvalid
ORDER BY c.relpages DESC LIMIT 10;

非常重要：通过验证注释掉 (AND n.nspname = 'pg_catalog' + LIMIT 10) 限制，以便对您的索引也运行 bt_index_check 函数！

是的，如果找到损坏的索引，该函数会抛出异常。

为什么索引会出错？ 我们如何确定我们的新数据库是一致的并且升级成功了？

Answer 1

为什么索引会出错？

最可能的解释是 CentOS 7 和 CentOS 8 之间的 glibc 版本不同。

This blog post 对此提供了更多见解。

通常在更改 glibc 版本时（例如，由于系统补丁或操作系统升级），您应该重新索引包括 text、varchar 或 char 列的所有索引。

这不是 Postgres 可以直接影响的，尽管使用 ICU 排序规则的能力是该问题的部分答案。但是如果操作系统的 ICU 版本被更新（例如，由于系统补丁再次隐式更新）你会在那里遇到同样的问题（但似乎 ICU 库的更新频率低于 glibc 库）

我认为至少有一些工作正在进行中以警告用户。但据我所知，当前版本 12 或即将发布的版本 13 中没有任何承诺。