PostgreSQL修改表后遇Cached plan错误，autosave无效求最优方案

得先把这个参数的作用说透——它是PostgreSQL JDBC驱动用来控制事务自动保存点的，意思是当事务执行中出现错误时，驱动会自动回滚到最近的保存点，而不是让整个事务直接失败。它和预编译语句的缓存没有任何关系，而你遇到的Cached plan must not change result type错误，根源是客户端或服务器端缓存的预编译执行计划，和变更后的表结构（字段长度调整、新增字段）的结果类型不匹配。所以设置这个参数根本踩不到问题的点上，自然解决不了。

这个参数的作用是彻底禁用JDBC客户端的预编译语句缓存：当值设为0时，驱动不会缓存任何预编译的PreparedStatement，每次执行SQL都会重新解析、生成新的执行计划。这样就不会出现旧缓存计划和新表结构不兼容的情况，但代价也很明显——对于频繁执行的SQL，每次都要重复解析，性能肯定会受影响。

我推荐你按优先级尝试这些方案，既能解决问题，又能尽量保留预编译的性能优势：

1. DDL变更后刷新连接池（最直接高效） #

当你修改完表结构后，重启应用或者强制刷新连接池里的所有连接。因为每个数据库连接都有自己独立的预编译语句缓存，刷新连接会直接清除这些旧的缓存计划，新建立的连接会基于更新后的表结构生成正确的执行计划。这是最快解决问题的方法，平时完全不影响性能。

2. 合理调整prepareThreshold参数（平衡性能与稳定性） #

别直接设为0，而是根据你的业务场景设置一个合适的阈值（默认是5，你可以调到10或20）。这个参数的逻辑是：同一条SQL执行次数超过这个阈值时，驱动才会缓存预编译计划。这样一来，只有那些高频执行的核心业务语句才会被缓存，大大降低了缓存计划遇到表结构变更的概率——毕竟你不会天天改表结构，而核心语句的结构通常也不会轻易变动。

3. 针对特定语句禁用预编译 #

如果某些语句经常伴随表结构变更（比如报表类查询、临时统计语句），可以在代码或框架层面单独禁用这些语句的预编译：

• JDBC层面：直接用Statement代替PreparedStatement执行这类SQL；
• ORM框架（比如MyBatis）：在对应的<select>/<update>标签里设置statementType="STATEMENT"；
• Spring JDBC：用JdbcTemplate的execute方法直接执行原始SQL，而非预编译方法。

4. 服务器端计划缓存控制（谨慎使用） #

如果问题出在PostgreSQL服务器端的计划缓存，可以考虑把plan_cache_mode参数设为force_custom_plan，强制服务器每次都生成新的执行计划，不再复用缓存的计划。不过这个参数是全局生效的，会影响所有查询的性能，只建议在你的系统频繁做表结构变更，且服务器端缓存是主要问题时使用。

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