X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 425E6D1B211
	for <pgsql-admin-postgresql.org@localhost.postgresql.org>;
	Thu, 22 Jul 2004 00:12:20 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 84128-08
	for <pgsql-admin-postgresql.org@localhost.postgresql.org>;
	Thu, 22 Jul 2004 03:12:23 +0000 (GMT)
Received: from mail.coretech.co.nz (coretech.co.nz [202.36.204.41])
	by svr1.postgresql.org (Postfix) with ESMTP id 33989D1B366
	for <pgsql-admin@postgresql.org>; Thu, 22 Jul 2004 00:12:17 -0300 (ADT)
Received: (qmail 8045 invoked from network); 22 Jul 2004 03:12:20 -0000
Received: from unknown (HELO coretech.co.nz) (10.0.10.28)
	by 0 with SMTP; 22 Jul 2004 03:12:20 -0000
Message-ID: <40FF3095.3030001@coretech.co.nz>
Date: Thu, 22 Jul 2004 15:12:21 +1200
From: Mark Kirkwood <markir@coretech.co.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-admin@postgresql.org
Subject: Re: [HACKERS] Point in Time Recovery
References: <200407132242.i6DMgg612564@candle.pha.pa.us>
	<1089760416.17493.3327.camel@stromboli>
	<40F49AE9.2060805@familyhealth.com.au>
	<1089789682.17493.3890.camel@stromboli>
	<40FF1D88.30404@coretech.co.nz> <2110.1090463955@sss.pgh.pa.us>
In-Reply-To: <2110.1090463955@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests=
X-Spam-Level: 
X-Archive-Number: 200407/242
X-Sequence-Number: 14310

Well that is interesting :_)


Here is what I am doing on the removal front (I am keeping pg_xlog *now*):

$ cd $PGDATA
$ pg_ctl stop
$ ls|grep -v pg_xlog|xargs rm -rf

The contents of the archive directory just before recovery starts:

$ ls -l $PGDATA/../7.5-archive
total 49212
-rw-------    1 postgres postgres 16777216 Jul 22 14:59 
000000010000000000000000
-rw-------    1 postgres postgres 16777216 Jul 22 14:59 
000000010000000000000001
-rw-------    1 postgres postgres 16777216 Jul 22 14:59 
000000010000000000000002

But here is recovery startup log:

LOG:  database system was shut down at 2004-07-22 14:58:57 NZST
LOG:  starting archive recovery
LOG:  restore_command = "cp /data1/pgdata/7.5-archive/%f %p"
cp: cannot stat `/data1/pgdata/7.5-archive/00000001.history': No such 
file or directory
LOG:  restored log file "000000010000000000000000" from archive
LOG:  checkpoint record is at 0/A4D3E8
LOG:  redo record is at 0/A4D3E8; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 496; next OID: 17229
LOG:  archive recovery complete
LOG:  database system is ready

regards

Mark

Tom Lane wrote:

>
>Huh?  It works fine.
>
>The bit you may be missing is that if you blow away $PGDATA including
>pg_xlog/, you won't be able to recover past whatever you have in your WAL
>archive area.  The archive is certainly not going to include the current
>partially-filled WAL segment, and it might be missing a few earlier
>segments if the archival process isn't speedy.  So you need to keep
>those recent segments in pg_xlog/ if you want to recover to current time
>or near-current time.
>
>
>  
>