Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YB1XI-0003q3-8X for pgsql-admin@arkaria.postgresql.org; Tue, 13 Jan 2015 13:29:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YB1XH-0003SH-38 for pgsql-admin@arkaria.postgresql.org; Tue, 13 Jan 2015 13:29:31 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YB1XF-0003S4-VE for pgsql-admin@postgresql.org; Tue, 13 Jan 2015 13:29:30 +0000 Received: from mail-ie0-x22d.google.com ([2607:f8b0:4001:c03::22d]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YB1XC-00088H-JO for pgsql-admin@postgresql.org; Tue, 13 Jan 2015 13:29:28 +0000 Received: by mail-ie0-f173.google.com with SMTP id y20so2653614ier.4 for ; Tue, 13 Jan 2015 05:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Gp8Zlntdk52plZXuXYRVG9VrTfF0ilFeep9+fgWysmA=; b=NapPjeC6y4VDYKhpcELG5YDv6C98ijW8VPDuqTbAegXRRQueahzpV5Ft94UOyek9zv ndKD19XvzvE2z/rIp6PtQOESWKfPwYwXZEiVa1ABPKzhQSAmd3IfOp3PcfAa0KJLNBHd u3Z2Af1uhmKIwYIlX3tNkPd0+uxhu00cHHq44P9Yr6X9r8QYYExuXANHg3YFeHGzEGab sn87jM+N4A5TsqtJIKfPnx9PEujV4QtRYR8ohclA8wACgjblqzEtl0SH4bqDNJPP0ZbC jqqB3S+kZ1dg5To95CPXppEUjk6NdHQdDDc4rWB1zN2YnHD8gjaZS2dAD7cVvuwl/cZK VNog== X-Received: by 10.42.65.74 with SMTP id k10mr29529648ici.42.1421155765299; Tue, 13 Jan 2015 05:29:25 -0800 (PST) Received: from [192.168.254.2] (h77.89.102.166.static.ip.windstream.net. [166.102.89.77]) by mx.google.com with ESMTPSA id m11sm6082249igt.7.2015.01.13.05.29.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jan 2015 05:29:24 -0800 (PST) Message-ID: <54B51DAA.5070605@gmail.com> Date: Tue, 13 Jan 2015 08:29:14 -0500 From: John Scalia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "pgsql-admin@postgresql.org" Subject: V9.4.0 standby server will not start Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin