Postgres升级至13.6时如何核查与Spring Data JPA的兼容性

• 第一步先对齐JDBC驱动版本
  PostgreSQL 13大版本要求JDBC驱动版本至少为42.2.x及以上，禁止使用42.1.x及更早版本。如果当前Spring Boot版本默认管理的postgresql驱动版本低于42.2，直接在pom.xml（Maven）或build.gradle（Gradle）里显式指定驱动版本即可，推荐选42.2.27（适配JDK8的稳定版）或对应你项目JDK版本的更高小版本。高版本JDBC驱动可以向下兼容低版本Postgres，你可以先替换驱动连现有10.6环境跑通所有测试，提前排雷，不用等数据库升级完成再换驱动。
• 第二步核查Hibernate方言配置
  Spring Data JPA底层依赖Hibernate实现，不要硬编码写死org.hibernate.dialect.PostgreSQL95Dialect或更老版本的Postgres方言类。如果是Spring Boot 2.2及以上版本，直接删掉手动配置的方言参数，让框架自动识别数据库版本即可；如果是老版本Spring Boot必须手动指定方言，配置成org.hibernate.dialect.PostgreSQL10Dialect就可以覆盖Postgres 13的所有基础语法，Postgres本身大版本对标准SQL的向后兼容性很强，不会因为方言问题出现基础CRUD报错。
• 第三步排查原生SQL与专属特性的兼容问题
  跨3个大版本的不兼容点基本都集中在自定义原生SQL、Postgres专属特性上，全局搜索项目里所有nativeQuery = true的@Query注解、XML映射SQL、代码拼接SQL，重点排查以下几类问题：
  • 有没有使用pg_current_xlog_location()这类老版本WAL相关函数，Postgres 10之后这类函数统一改名为pg_current_wal_lsn()前缀，老函数在13版本里已经被完全移除，调用会直接报错
  • 有没有依赖老版本CTE（WITH子句）默认物化的副作用写业务逻辑，Postgres 12之后CTE默认会被优化器内联，如果之前的SQL依赖CTE提前执行、避免重复计算的特性，需要手动给CTE加MATERIALIZED关键字
  • 有没有用到JSONB路径查询、array_to_string/string_to_array数组函数、全文检索tsvector类型的特殊逻辑，13版本对这些特性的空值处理、大小写校验规则和10版本有细微差异，要单独拿业务场景验证
  • 如果项目用了ltree、hstore、Postgres数组这类专属字段类型，重点验证字段映射、序列化、查询条件传参是否正常，这类扩展类型跨版本最容易出现类型不匹配的报错
• 第四步核查周边持久层依赖版本
  如果项目用Flyway/Liquibase做数据库版本迁移，确保Flyway版本≥7.0、Liquibase版本≥4.0，低版本迁移工具识别不到Postgres 13的版本号，启动时会直接抛版本不兼容错误。如果搭配了QueryDSL、MyBatis-Plus等其他持久层工具，只要JDBC驱动版本匹配，基本不会有兼容问题，重点验证下复杂分页、多表关联查询的SQL生成逻辑即可。
• 第五步做预升级实机验证
  1. 拉取一份现有10.6环境的全量数据备份，恢复到本地部署的Postgres 13.6实例，先用pg_upgrade工具自带的兼容性检查参数扫一遍数据库层面的不兼容项，先把数据库侧的问题清掉
  2. 把项目数据库连接指向这个13.6测试实例，跑完全量单元测试、集成测试，重点排查SQL报错、字段映射错位、事务回滚异常三类问题
  3. 把核心业务链路的慢查询、高频查询单独拿出来在13.6实例上跑执行计划，确认索引命中正常，没有因为查询优化器规则变化导致的性能陡降

实际经验来看，Postgres 10到13没有做核心SQL语法的破坏性删除，90%以上的兼容问题都集中在驱动版本过低、硬编码老版本方言、调用了被移除的小众内置函数这三类，这三点排查完基本不会有阻塞性问题。

内容的提问来源于stack exchange，提问作者Rupesh Kumar Sahu