PostgreSQL开源免费企业级数据库用着不爽的案例

最近审批了一个pg数据库ddl表结构变更的工单

变更SQL如下所示：
ALTER TABLE t_table_bind_info ALTER COLUMN third_user_id TYPE varchar(128);

原先长度小于128，本次变更为扩容varchar长度。

审批没多久后发现有CPU等告警，立即查看各监控指标和错误日志、慢日志等信息。

发现监控多项指标异常

1，DDL执行结束后立即出现错误日志 ERROR: cached plan must not change result type

2，30秒之后出现业务慢日志 ERROR: canceling statement due to statement timeout 信息。

我收到CPU告警信息后立即去手动analyze收集刚刚ddl的表统计信息，之后CPU，慢查询等立即恢复正常，业务影响消失。

其实这是两个问题，第一个关于ERROR: cached plan must not change result type报错，原因如下：

PostgreSQL的优化器和Oracle等库一样都是比较复杂的，可能会使用绑定变量，减少sql parser, plan的开销，但是当我们做数据库表结构的DDL变更时，缓存中的执行计划与结果类型就会不匹配，就会报ERROR: cached plan must not change result type报错，关于这个报错有多种解决办法如重启业务程序，杀掉数据库会话连接，deallocate the prepare等方法。但是由于当前各业务都是使用的ORM框架生成的SQL，另外我们属于OLTP在线业务，肯定是不能随意做上述操作的，我们能做的只能是在业务相对低峰期审批执行类似的工单，减少对业务的影响。

第二个报错ERROR: canceling statement due to statement timeout，是因为执行计划选择出现了问题，

超时SQL 条件为WHERE third_user_id = $1 and third_app_type = $2
and third_app_name = $3 and is_delete = false order by update_time desc limit 1

third_app_type长度变更后导致执行计划走到order by update_time索引上，从而引起慢查询，看起来有必要在业务DDL工单执行完毕后再去自动analyze 一下目标表了，这样可以减少类似问题的发生，接下来需要尽快优化这一步。