Trying again,
Last Friday, I started setting up this new cluster, and I download the following 4 rpms from the postgresql site and the rhel-6.5-x86_64 directory, all were timestamped as 17 Dec 2014:
postgresql94-9.4.0-1PGDG.rhel6.x64_64.rpm
postgresql94-libs-9.4.0-1PGDG.rhel6.x64_64.rpm
postgresql94-server-9.4.0-1PGDG.rhel6.x86_64.rpm
postgresql94-contrib-9.4.0-1PGDG.rhel6.x86_64.rpm
My three servers are all CentOS 6.5 (virtualized). I went through all the server configuration files. These servers have been running V9.3.3 as a master with two standbys, and
V9.4.0 was installed alongside 9.3.3. The older version was stopped using "service postgresql-9.3 stop".
Modifications of postgresql.conf file were done in accordance with the instructions at https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.4. The master server started
with no problems, and a replication slot called "standby_replication_slot_one" was created on it. I can see it via "select * from pg_replication_slots;". The standby servers were
then modified so that their recovery.conf file contained "primary_slotname = standby_replication_slot_one" it it. The recovery conf file originated and was operational for V9.3.3.
Only one slot currently exists and I have not started configuring for the second standby server. The first standby server fails to start using "service postgresql-9.4 start". The
postgresql-Mon.log shows:
#[root@csgha1] more postgresql-Mon.log
< 2015-01-12 12:07:15.543 @ > @FATAL: unrecognized recovery parameter "primary_slotname"
And that's the problem that I do not understand. Sorry to be so long winded, but I wanted to be thorough. Why is the standby throwing this error? It appears that the build is still
using an older parser, but I've verified that the whole thing is using 9.4 binaries.
--
Jay
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
