PostgreSQL提示collation version mismatch，升级glibc后怎么处理？

Linux 升级 glibc、ICU 或操作系统后，PostgreSQL 可能提示 collation version mismatch。这是数据库记录的排序规则版本与系统当前提供的版本不同，旧索引可能仍按照原来的比较顺序构建。

不要只执行 REFRESH VERSION 消除警告。官方文档明确说明，刷新版本不会检查受影响对象是否已经重建。 正确顺序是识别依赖对象、重建可能受影响的结构，再更新版本记录。

查出哪些排序规则版本不一致

以具备目录查询权限的数据库账号执行：

SELECT collname,
       collprovider,
       collversion AS recorded_version,
       pg_collation_actual_version(oid) AS actual_version
FROM pg_collation
WHERE collversion IS DISTINCT FROM pg_collation_actual_version(oid);

collprovider 可以帮助区分 libc、ICU 等提供者。还要确认告警来自命名排序规则，还是数据库默认排序规则：

SELECT datname, datcollversion
FROM pg_database
WHERE datname = current_database();

版本字符串不同并不能直接说明所有数据已经损坏，但表示旧排序顺序与当前系统可能不一致。涉及文本索引、唯一约束和依赖排序规则的对象都应纳入评估，不能只看业务是否暂时还能查询。

定位依赖排序规则的对象

PostgreSQL 官方文档提供了依赖查询，可从目标排序规则 OID 查找相关对象：

SELECT pg_describe_object(refclassid, refobjid, refobjsubid) AS collation,
       pg_describe_object(classid, objid, objsubid) AS object
FROM pg_depend
WHERE refclassid = 'pg_collation'::regclass
  AND refobjid = 'public.example_collation'::regcollation
ORDER BY 1, 2;

把示例排序规则替换为实际名称。还应通过应用模式、索引定义和约束清单确认依赖范围，尤其关注使用非默认 collation 的表达式索引、唯一索引和分区键。

维护前记录查询结果、数据库版本、操作系统排序库版本，并准备可验证的备份。排序规则变化可能影响比较结果和唯一性判断，生产库应安排维护窗口，而不是在高并发期间直接刷新。

先重建受影响的索引和对象

对确认受影响的单个索引，可根据版本和业务可用性选择普通或并发重建：

REINDEX INDEX public.example_text_idx;

需要降低写阻塞时，可在满足版本与对象限制的前提下使用：

REINDEX INDEX CONCURRENTLY public.example_text_idx;

依赖范围较大时可按表、模式或数据库制定重建计划，但要评估额外磁盘空间、锁等待和执行时长。并发重建也不是零成本，失败后可能留下无效索引需要清理。先备份、确认空间并逐批验收，避免一次性对整个生产数据库执行高风险重建。

如果对象不是索引，应按对象类型重新生成或刷新，例如重新创建依赖排序的物化结果。具体范围应以依赖查询和应用数据模型为准。

重建完成后再刷新版本记录

所有受影响对象处理完毕后，刷新命名排序规则版本：

ALTER COLLATION public.example_collation REFRESH VERSION;

如果告警来自数据库默认排序规则，使用：

ALTER DATABASE exampledb REFRESH COLLATION VERSION;

这些命令主要更新 PostgreSQL 记录的版本值。REFRESH VERSION 本身不会验证索引是否重建，也不会自动修复旧排序顺序。 若缺少权限，应由数据库所有者或具备相应权限的管理员执行。

准备迁移或大版本升级时，可先在 萤光云 或 LightNode 的隔离实例恢复备份，验证排序、唯一约束和重建耗时，再安排生产维护窗口。

验证版本、索引和业务排序结果

重新运行版本检查，确认记录值与当前值一致：

SELECT collname,
       collversion,
       pg_collation_actual_version(oid) AS actual_version
FROM pg_collation
WHERE collversion IS DISTINCT FROM pg_collation_actual_version(oid);

再检查无效索引：

SELECT indexrelid::regclass AS index_name
FROM pg_index
WHERE NOT indisvalid;

最后执行应用侧的典型排序、范围查询、大小写或重音比较和唯一写入测试。验收标准是版本不再不匹配、受影响索引有效、数据库日志无新告警，并且关键查询与唯一性行为符合业务预期。

FAQ

出现警告是否代表表数据已经损坏？

不一定，但旧索引可能按旧排序规则构建，查询顺序和唯一性判断存在风险。应按依赖范围重建并验证，不能仅凭表能读取就忽略。

只执行ALTER COLLATION REFRESH VERSION可以吗？

不可以把它当作修复。该命令只更新版本记录，不会检查或重建依赖对象，可能让警告消失却保留风险。

托管PostgreSQL也能直接执行这些命令吗？

取决于云厂商的升级流程、权限和维护机制。应先阅读对应服务的维护公告与操作文档，确认排序库升级是否由平台代管以及允许的重建方式。

温馨提示

排序规则版本处理的核心顺序是先盘点依赖、再重建对象、最后刷新版本并做业务验收。 在生产环境操作前请验证备份可恢复、预留重建空间和回滚时间；大型索引应分批处理并持续观察锁等待、复制延迟和磁盘使用量。