Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id 3A3111337B99
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Mon,  3 Jan 2011 16:24:40 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 20183-03-3
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Mon,  3 Jan 2011 20:24:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id DF07B1337B93
	for <pgsql-admin@postgresql.org>; Mon,  3 Jan 2011 16:24:29 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p03KOQPf024374;
	Mon, 3 Jan 2011 15:24:26 -0500 (EST)
To: Imre Oolberg <imre@auul.pri.ee>
cc: Scott Ribe <scott_ribe@elevated-dev.com>, pgsql-admin@postgresql.org
Subject: Re: Re: pg v. 8.4.5 misses objects and data after restoring from
	backup using wal
In-reply-to: <4D222E45.2080701@auul.pri.ee> 
References: <AANLkTikY_XJ0Ok7bLGVxXXfGgenfnzJ4RnSiM_H40FCM@mail.gmail.com>
	<4D2213EB.7090700@auul.pri.ee>
	<42066935-6D27-46E3-8094-836D204816B7@elevated-dev.com>
	<22500.1294080152@sss.pgh.pa.us>
	<E486B5B1-EC5F-4615-8633-D89CF6665663@elevated-dev.com>
	<22730.1294081008@sss.pgh.pa.us> <4D222E45.2080701@auul.pri.ee>
Comments: In-reply-to Imre Oolberg <imre@auul.pri.ee>
	message dated "Mon, 03 Jan 2011 22:15:01 +0200"
Date: Mon, 03 Jan 2011 15:24:26 -0500
Message-ID: <24373.1294086266@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201101/20
X-Sequence-Number: 36460

Imre Oolberg <imre@auul.pri.ee> writes:
> First of all, thanks for your time dealing with my situation. I must 
> stress that i have wal arhived starting from before issuing 
> pg_start_backup, wal archives generated before pg_start/stop_backup and 
> also some wal archive files generated after pg_stop_backup (and 
> permissions are ok). But for some reason my replay starts exactly where 
> .backup file says 'stop wal location', referring to my earlier post

> STOP WAL LOCATION: 1/6325B2E0 (file 000000010000000100000063)

> I am starting to think more in the direction what Kevin Grittner 
> suggested that i miss something in my procedure and instead following so 
> to say recovery path i am doing something else which strangely ends up 
> with working database process but actually misses some data.

I wonder whether you're failing to copy the backup_label file as part of
the base backup.  The presence of that file is what tells the slave
postmaster where it has to start recovering from.

			regards, tom lane