PostgreSQL备库rsync升级及延迟副本升级的技术疑问

问题一：主库升级后能否启动验证，备库升级的限制 #

官方文档的描述是准确的。

在链接模式下，新旧版本的PostgreSQL数据目录通过硬链接共享底层数据文件，并没有真正复制数据。如果此时启动升级后的主库，新版本PostgreSQL会立即修改共享的元数据文件、写入新版本格式的WAL日志，这会直接破坏旧版本备库依赖的原始数据状态——因为备库需要基于主库升级后未被改动过的数据目录来执行rsync同步。

一旦主库启动过，就不能再用这种rsync快速升级备库的方式，只能重新对升级后的主库做基础备份，再搭建备库，这就失去了链接模式+rsync的高效性。并非备库完全无法升级，只是无法再使用文档中提到的快速升级路径。

问题二：延迟副本的升级方式 #

基于归档WAL传输和recovery_min_apply_delay的延迟副本，不能用rsync快速升级的方式。

核心原因是PostgreSQL不同大版本的WAL日志格式不兼容：旧版本生成的WAL无法在新版本实例中解析应用，新版本的WAL也不能被旧版本识别。延迟副本上还留存着未应用的旧版本WAL，若用rsync同步主库升级后的新版本数据目录，这些旧WAL和新版本数据目录完全不匹配，无法继续完成延迟应用。

这种情况下，只能通过对升级后的主库做全新的基础备份，重新搭建延迟副本，之前未应用的延迟WAL会全部丢失，因为它们无法在新版本环境中使用。

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