PostgreSQL 19 inet/cidr索引变更：哪些旧索引会挡住升级

这次改动并非把全部inet/cidr索引换一种类型。19调整的是GiST默认操作符类，也就是索引比较与检索地址所采用的规则，普通B-tree不在相同替换范围内。

重点排查btree_gist的gist_inet_ops和gist_cidr_ops。旧库保留这类索引时，pg_upgrade会要求处理，应在正式停机前先找出来。

一、为什么要改？影响的不只是速度

inet、cidr保存IP和网络地址。GiST为它们选择哪套操作符类，会影响值在索引里的表示方法，以及怎样找出可能符合条件的记录。

旧的两类 btree_gist 操作符类存在可靠性问题，索引查找可能漏掉本来应该返回的行。因此，19 改为默认采用内置的 inet_ops。这个变化首先关心结果正确，而不只是某种查询快一点。

已有索引不会因为默认值改变，就原地自动变成另一套规则。REINDEX 通常仍按原来的索引定义重建，也不能当作更换操作符类的通用办法。

二、怎么知道自己的库有没有受影响？

要在每个业务数据库分别查，不要只看有没有安装 btree_gist。安装了扩展，不代表一定建过这两类索引；真正要找的是实际索引依赖。

有结果就把表、索引和定义保存下来；没有结果也要完成 pg_upgrade --check 及其他升级检查。这条查询只负责找这一类问题，不代表整个数据库已经适合升级。

三、普通索引怎样替换？

对于不负责约束的简单索引，可以先新建使用内置操作符类的索引，再核对查询和新索引状态，最后移除旧索引。下面只是单列普通索引的示例：

这里的表名、列名和索引名需要替换；应先确认源版本具备这套内置操作符类，并在测试库验证。新索引创建成功后，检查它是否有效，再测试典型查询的结果和执行计划。

不要照抄示例后，立刻删除所有旧索引。多列索引、表达式索引、部分索引和分区索引，都要保留原有设计中的其他条件，逐一制定替换步骤。

四、排他约束不能按普通索引直接删

某些 GiST 索引是排他约束的组成部分，负责阻止不允许的数据组合。直接删索引可能做不到，也可能让你在重建约束时失去原有保护。

把约束结果与受影响索引对应起来。涉及约束的情况，要单独考虑数据检查、锁、维护窗口及重建顺序。不能套用“并发建一个新索引再删除旧索引”这一个模板。

五、换完以后检查什么？

处理完旧规则对应的索引后，再执行19的pg_upgrade --check。业务测试还要覆盖实际使用的相等、范围、网络包含和空值条件。

走导出恢复也不能忽略定义：如果脚本明确写了旧操作符类，新默认值不会自动覆盖脚本里的指定内容。

排查关键是确认每个索引真正采用的规则，不是只找inet/cidr列。提前整理对象和替换计划，比停机后临时处理更稳妥。