为什么我的 postmaster 进程（有时）在 WAL 基础恢复后变得无法管理？

TL;DR：在从 WAL 基础备份恢复其数据目录后立即启动 Postgres 时，会生成不可停止、无法使用的 postmaster。为什么？

语境：

我们使用 PGDG 包在 CentOS 6 上运行 postgresql 8.4。我们有一个用于开发人员测试环境的脚本，用于恢复生产服务器数据目录的夜间备份（在调用pg_start_backup和之间创建pg_stop_backup）。该脚本解压缩文件，并用于restore_command重新应用在生产中进行备份期间生成的任何 WAL。

它通常工作正常，并且恢复速度比基于 SQL 的pg_dump'ed 文件恢复快数百倍。

问题：

有时，在解压数据目录后，脚本会通过运行启动 postgres /etc/init.d/postgresql start（这是指向 . 的符号链接/etc/init.d/postgresql-8.4。这使它成为我们最终升级到 9.* 时可预测的初始化脚本）。它报告“OK”，如：它正确启动。然后 WAL 不会恢复；它无限期地挂起等待recovery.done文件出现。

我试过的：

当我/etc/init.d/postgresql status在无限期挂起期间运行时，初始化脚本报告dead but pid file exists.

然后我跑了ps -ef | grep post。奇怪的是，postmaster 进程和归档器等正在运行。所有调用参数都是正确的（正确的 datadir 等）。

当我运行psql时，它检测到一个正在运行的 postmaster 和一个初始化的postgres数据库，但没有检测到主数据库——我们关心通过 WAL 脚本恢复的那个。

然后我检查了数据目录上的权限，一切看起来都很好。

运行/etc/init.d/postgresql stop报告“OK”，并终止归档程序/观察程序进程，但 postmaster 保持运行。

我尝试时也发生了同样的事情killall -r '*.postmaster*.'。

唯一可以恢复卡住的 WAL 恢复的是killall -s 3 -r '.*postmaster.*'（信号 3 是 SIGQUIT），然后是/etc/init.d/postgresql start.

我在无法管理的状态下检查pg_startup.log了每日文件pg_log，一切看起来都很好。pg_startup.log将成功启动注册为最后一个条目。

可能的原因：

关于我们的配置，有一些（我认为是次要的）事情是非标准的。

• 正如我之前所说，我们的 init 脚本符号链接到一个与版本无关的脚本，位于/etc/init.d/postgresql. 这指向我们想要的任何地方。目前它指向/etc/init.d/postgresql-8.4.

• 我们的postgresql.conf文件位于/etc/（具有 postmaster 用户的所有者和组），并具有指向数据目录的符号链接。我们的 WAL 恢复脚本确保在尝试启动 postgres 之前重新创建符号链接。

• 我们最近将基础架构从 Postgresql 8.4.11 升级到了 8.4.12。我们正在测试新版本的稳定性。我们的生产服务器正在运行 8.4.11。但是，我们通过 将数据从它们中提取出来，对其进行pg_dump清理，然后将其“打包”以在其他地方（在 8.4.12 上）进行 WAL 恢复，因此我们不会跨不兼容的 Postgres 版本恢复 WAL。

问题：

为什么要这样做？下面列出的可能原因之一可能是罪魁祸首吗？