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 26C59D1B23E for ; Thu, 22 Jul 2004 20:49:03 -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 11881-09 for ; Thu, 22 Jul 2004 23:48:57 +0000 (GMT) Received: from cmailm3.svr.pol.co.uk (cmailm3.svr.pol.co.uk [195.92.193.19]) by svr1.postgresql.org (Postfix) with ESMTP id 430C8D1B16A for ; Thu, 22 Jul 2004 20:48:53 -0300 (ADT) Received: from modem-2449.lion.dialup.pol.co.uk ([217.135.169.145] helo=[192.168.0.102]) by cmailm3.svr.pol.co.uk with esmtp (Exim 4.14) id 1BnnIz-00038O-JC; Fri, 23 Jul 2004 00:48:53 +0100 Subject: Re: [HACKERS] Point in Time Recovery From: Simon Riggs To: Tom Lane Cc: Mark Kirkwood , pgsql-admin@postgresql.org In-Reply-To: <12173.1090527593@sss.pgh.pa.us> 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> <12173.1090527593@sss.pgh.pa.us> Content-Type: text/plain Organization: 2nd Quadrant Message-Id: <1090540113.3057.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 23 Jul 2004 00:48:34 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.1 tagged_above=0.0 required=5.0 tests=RCVD_IN_SORBS X-Spam-Level: X-Archive-Number: 200407/260 X-Sequence-Number: 14328 On Thu, 2004-07-22 at 21:19, Tom Lane wrote: > Mark Kirkwood writes: > > 2) Is is possible to make the recovery kick in even though pg_control > > says the database state is shutdown? > > Yeah, I think you are right: presence of recovery.conf should force a > WAL scan even if pg_control claims it's shut down. Fix committed. > This *should* be possible but I haven't tested it. There is a code path on secondary checkpoints that indicates that crash recovery can occur even when the database was shutdown, since the code forces recovery whether it was or not. On that basis, this may work, but is yet untested. I didn't mention this because it might interfere with getting hot backup to work... Best Regards, Simon Riggs