Postgres 10.20升级至10.22后varchar列'='匹配失效求助

核心现象 #

• Docker部署的Postgres从10.20升级到10.22（保留原有数据目录）后，部分varchar(48)类型的用户名无法通过where username = '[用户名]'精确匹配，但使用where username like '%[用户名]%'可正常匹配
• 回退至10.20版本后，=匹配恢复正常

可能原因及验证方式 #

1. 字符集/排序规则的隐性变更 #

Docker镜像的10.22版本可能调整了默认的LC_COLLATE或LC_CTYPE参数（系统区域设置），而你未在容器启动时显式指定这些参数，导致字符串比较规则发生变化。=匹配依赖排序规则定义的字符相等性逻辑，而like操作是基于字节或简单模式匹配，不受复杂排序规则的影响。

• 验证：分别在两个版本中执行show lc_collate;和show lc_ctype;，对比输出是否一致。

2. 索引损坏或未正确加载 #

升级过程中，若Docker挂载的数据目录存在权限异常，可能导致username字段对应的索引损坏或未正确加载。精确匹配通常会走索引查询，而带前导%的like操作多为全表扫描，因此不受索引问题影响。

• 验证：对username字段的索引执行REINDEX INDEX index_name;（替换为实际索引名），之后测试=匹配是否恢复。

3. 小版本补丁的隐性字符串逻辑调整 #

虽然官方文档未明确提及varchar相关变更，但10.20到10.22之间的补丁可能修复了特殊字符（如空格、非ASCII字符、组合字符）的相等性判断逻辑。若问题用户名包含这类字符，补丁可能改变了原本的匹配结果。

• 验证：提取问题用户名，在两个版本中执行SELECT '[问题用户名]' = '[问题用户名]'::varchar(48);，对比返回结果；或用octet_length(username)检查存储的字节长度是否存在差异。

临时修复建议 #

• 容器启动时显式指定LC_COLLATE和LC_CTYPE参数，与10.20版本保持一致，例如：

  docker run ... --env LC_COLLATE=en_US.utf8 --env LC_CTYPE=en_US.utf8 ...
  

• 重建涉及username字段的所有索引。

内容的提问来源于stack exchange，提问作者Travis Lu