标准答案
- 升级前记录 PostgreSQL 主版本、扩展版本、客户端驱动、排序规则、SQL 特性和自定义类型，确认目标版本和所有扩展都有支持矩阵。
- 扩展升级不只是复制一个 SQL 文件；要确认目标环境已安装对应扩展包，并按扩展提供的 ALTER EXTENSION UPDATE 路径执行，不能随意手工改系统目录。
- DDL 的风险取决于锁、数据量和版本行为。大表加索引、回填和约束应拆成可观测步骤，必要时使用 CONCURRENTLY，并设置合理的 lock_timeout。
- 应用和结构要采用 expand/contract：先增加新结构并让旧代码兼容，再双写或回填、切换读写，最后确认没有旧版本实例后清理旧结构。
- 回滚计划必须区分代码回滚和数据库回滚。不可逆 DDL、数据转换和扩展升级常不能简单 downgrade，应准备向前修复、备份恢复或 PITR 路径。
题目解析
数据库迁移改变的是共享状态，应用实例可能在一段时间内同时运行旧版本和新版本。因此最重要的不是某条 DDL 写得多短，而是新旧代码能否在兼容窗口内共同工作，以及失败后能否继续服务。
“迁移成功”至少要看执行结果、锁等待、耗时、数据回填进度和复制影响。某些操作会长时间占用 I/O 或阻塞写入，即使最终返回成功，也可能已经造成业务尾延迟和复制积压。
上线前应使用生产规模数据或接近真实分布的副本演练，并验证扩展、驱动、备份恢复和监控。数据库变更无法安全回滚时，要把向前修复脚本和明确的止损条件作为发布物的一部分。
常见误区
- 误区：在生产高峰直接执行大表 DDL。改正：先评估锁和重写行为，在副本或影子环境演练，再拆分为可暂停、可观测的步骤。
- 误区：把数据库迁移工具的 down 脚本当成可靠回滚。改正：数据转换和扩展升级可能不可逆，应准备向前修复、备份恢复和业务降级方案。
- 误区：只确认 SQL 执行成功，不检查旧版本实例。改正：迁移完成后还要核对应用兼容、数据对账、复制延迟、慢查询和新旧代码流量。