Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-admin-owner+M42555=pgsql+2Dadmin=arkaria.postgresql.org@postgresql.org>)
 id 1Wy2s0-0005il-Vm
 for pgsql-admin@arkaria.postgresql.org; Fri, 20 Jun 2014 17:45:01 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-admin-owner+M42555=pgsql+2Dadmin=arkaria.postgresql.org@postgresql.org>)
 id 1Wy2s0-0006yn-Fk
 for pgsql-admin@arkaria.postgresql.org; Fri, 20 Jun 2014 17:45:00 +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 <jayknowsunix@gmail.com>)
 id 1Wy2rz-0006ya-9c
 for pgsql-admin@postgresql.org; Fri, 20 Jun 2014 17:44:59 +0000
Received: from mail-yk0-x231.google.com ([2607:f8b0:4002:c07::231])
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.80) (envelope-from <jayknowsunix@gmail.com>)
 id 1Wy2rw-0003Jv-BR
 for pgsql-admin@postgresql.org; Fri, 20 Jun 2014 17:44:57 +0000
Received: by mail-yk0-f177.google.com with SMTP id 10so2892068ykt.8
 for <pgsql-admin@postgresql.org>; Fri, 20 Jun 2014 10:44:55 -0700 (PDT)
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=YOZKxUxeRUeZEwqqO1y7j9VqNmoJGI3LwEY8+8En5lc=;
 b=iaWJxS2b/uE57Bc2+SU/KzyjmGl2rimD6jTRB0Uv0g+oJpjyH6xdDu/vDL1a3Pkpk1
 zo7rjDmOLgPgkt0pxpQi2IWLD9n6wv999l6iLVKHFal5JWDTHU4pSAHVHOStYc9B83Wp
 wCPlUNCj0DvkhMB+0yrFZjTkfGngij/bbCECeJSFw0ue2TGJIoL5xSl3gTLjd6otcWMz
 QVyL/6XfYfdF1fv8/uSFO6LoJdQp1nh3A2IxpYIANMxpkrgI8yP/++ZXC2SecDDzb4LS
 9p4hcOGtIZJRWayd/u8i5LKNM11P8C8px+n6uVdbBUnsf2Gj9bP+nsQtLQDpaYNqZlS6
 dRgQ==
X-Received: by 10.236.124.7 with SMTP id w7mr7192314yhh.33.1403286295734;
 Fri, 20 Jun 2014 10:44:55 -0700 (PDT)
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 e70sm15493812yhk.9.2014.06.20.10.44.55
 for <pgsql-admin@postgresql.org>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Fri, 20 Jun 2014 10:44:55 -0700 (PDT)
Message-ID: <53A47312.9040600@gmail.com>
Date: Fri, 20 Jun 2014 13:44:50 -0400
From: John Scalia <jayknowsunix@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: pgsql-admin@postgresql.org
Subject: Cannot rebuild a standby server
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -2.0 (--)
List-Archive: <http://archives.postgresql.org/pgsql-admin>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-admin.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@postgresql.org>
List-Post: <mailto:pgsql-admin@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-admin>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
X-Mailing-List: pgsql-admin
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

In the true definition of insanity, I've tried to rebuild a standby streaming replication server using the following steps several times:

1) ensure the postgresql data directory, /var/lib/pgsql/9.3/data, is empty.
2) run: pg_basebackup -h <primary server> -D /var/lib/pgsql/9.3/data
3) manually copy the WAL's from the primary server's pg_xlog directory to the directory specified in the standby's recovery.conf restore_command.
4) rm any artifacts from the standby's new data directory like the backup_label file.
5) copy the saved recovery.conf into the standby's data directory and check it is accurate.
6) Start the database using "service postgresql-9.3 start"

Every time, however, the following appears in the pg_log/postgresql-Fri.log:
<timestamp> LOG: entering standby mode
<timestamp> LOG: restored log file "00000003.history"
<timestamp> LOG: invalid secondary checkpoint record
<timestamp> PANIC: could not locate a valid checkpoint record

All this was originally caused by testing the failover mechanism in pgpool. That didn't succeed and I'm trying to get the servers back to their original states. I've done this kind 
of thing before, but don't know what's wrong with this effort. What have I missed?
--
Jay


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin