CentOS 6.5 上的 PostgreSQL 9.1-recovery.conf 导致进程退出并显示错误代码

CentOS 6.5 上的 PostgreSQL 9.1-recovery.conf 导致进程退出并显示错误代码

我在 Ubuntu 12.04 LTS 上设置了流式复制,并在发生故障时对 WAL 文件进行 rsyncing。现在我尝试在 CentOS 6.5 上执行相同操作。

为此,我添加了来自 postgresql.org 的官方 RPM,并使用 yum 安装了 postgresql 9.1。

一切都很好,直到我应该创建文件的步骤recovery.conf

只需在目录中创建空recovery.conf文件就足够了$PDATA,这样 PostgreSQL 就不会启动:

DEBUG:      PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
DEBUG:      MAIL=/var/spool/mail/root
DEBUG:      LC_IDENTIFICATION=pl_PL.UTF-8
DEBUG:      PWD=/var/lib/pgsql
DEBUG:      LANG=en_US.UTF-8
DEBUG:      LC_MEASUREMENT=pl_PL.UTF-8
DEBUG:      SELINUX_LEVEL_REQUESTED=
DEBUG:      HISTCONTROL=ignoredups
DEBUG:      HOME=/var/lib/pgsql
DEBUG:      SHLVL=2
DEBUG:      LOGNAME=postgres
DEBUG:      SSH_CONNECTION=10.255.0.142 41803 10.255.0.186 22
DEBUG:      LESSOPEN=|/usr/bin/lesspipe.sh %s
DEBUG:      LC_TIME=C
DEBUG:      G_BROKEN_FILENAMES=1
DEBUG:      LC_NAME=pl_PL.UTF-8
DEBUG:      _=/usr/pgsql-9.1/bin/postgres
DEBUG:      PGLOCALEDIR=/usr/pgsql-9.1/share/locale
DEBUG:      PGSYSCONFDIR=/etc/sysconfig/pgsql
DEBUG:      LC_COLLATE=en_US.UTF-8
DEBUG:      LC_CTYPE=en_US.UTF-8
DEBUG:      LC_MESSAGES=pl_PL.UTF-8
DEBUG:  -----------------------------------------
DEBUG:  invoking IpcMemoryCreate(size=39288832)
DEBUG:  usuwanie pliku "pg_notify/0000" # removing file
DEBUG:  max_safe_fds = 984, usable_fds = 1000, already_open = 6
DEBUG:  zatrzymanie rejestratora # means stop registry/registrator
DEBUG:  shmem_exit(0): 0 callbacks to make
DEBUG:  proc_exit(0): 0 callbacks to make
DEBUG:  exit(0)
DEBUG:  shmem_exit(-1): 0 callbacks to make
DEBUG:  proc_exit(-1): 0 callbacks to make

运行gdb时也是一样:

DEBUG:  shmem_exit(0): 0 callbacks to make
DEBUG:  proc_exit(0): 0 callbacks to make
DEBUG:  exit(0)
DEBUG:  shmem_exit(-1): 0 callbacks to make
DEBUG:  proc_exit(-1): 0 callbacks to make

Program exited with code 01.
(gdb) bt
No stack.

带有-d 5LC=C(太长,无法放入帖子中) http://pastebin.com/Z7t1CEwg

没有该 recovery.conf 文件,PostgreSQL 仍可正常运行。

有谁遇到过这样的问题吗?

答案1

此问题不会发生在 CentOS x64 上。这只是暂时的解决方法,但我接受它没有更好的答案。

相关内容