PostgreSQL在默认情况下，是不能跨版本升级的(9.4, 9.5, 9.6等等这些版本跨版本升级。小版本更新不受影响，比如9.6.1到9.6.2升级不受影响)。甚至PG为了数据的安全性，高版本不能直接使用低版本创建的数据目录，会在日志中打印相关的错误信息。
下面介绍两种升级方案可供选择，均是postgresql官方文档提及的方案（官方文档参考: ）。
dump + restore方案
此方案的原理是使用pg_dumpall命令将旧数据库的全部dump成sql文件，然后使用psql命令还原至高版本的实例中。借助于管道，可以实现在线升级。配合脚本的话，切换至高版本几乎零宕机。由于dump+restore总体相对耗时较长，因此不适用于大数据量的数据库，或是写入比较频繁的场景使用。
在线迁移的步骤大致如下:
- 保持旧的实例与配置运行
- 新的PG实例配置新的端口或者新的unix socket文件，确保不与旧实例冲突
- 使用
pg_dumpall|psql管道组合命令在线迁移数据 - 停止旧实例，将新实例的配置修改为旧实例使用的端口，重启服务即可完成迁移
参考命令如下:
sudo -u postgres pg_dumpall -h /path/to/old/instance.sock | sudo -u postgres psql -h /path/to/new/instance.sock
数据倒入完毕之后，停掉旧实例，删除旧数据的数据目录即可。
不需要在线升级的话，也可以先用pg_dumpall把旧实例的数据导出，再更新postgresql，清空数据目录，使用psql还原数据，效果是完全一样的。
pg_upgrade方案
pg_upgrade命令是直接对旧的数据库目录文件进行升级的方案，直接将旧版本的数据文件格式升级为新版本使用的格式。此方案优势是速度非常快，但是必须停机升级。因此不适用于7x24的场景。
命令非常简单，同时安装新版本和旧版本的postgresql，停止postgresql实例后执行:
sudo -u postgres pg_upgrade -b oldbindir -B newbindir -d olddatadir -D newdatadir
复制集方案
此方案是最平滑的方案，比较适用于7x24小时以及大数据量场景，停机时间非常短，只有几秒钟。缺点和优点同样突出——配置繁琐，需要有集群环境。
大体的步骤是使用Slony这种复制集方案，先用上述方案升级从库，再升级主库。