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 AA81CD1B380 for ; Thu, 22 Jul 2004 21:05:21 -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 16823-10 for ; Fri, 23 Jul 2004 00:05:23 +0000 (GMT) Received: from mail.coretech.co.nz (coretech.co.nz [202.36.204.41]) by svr1.postgresql.org (Postfix) with ESMTP id F27CDD1B2A6 for ; Thu, 22 Jul 2004 21:05:14 -0300 (ADT) Received: (qmail 30495 invoked from network); 23 Jul 2004 00:05:15 -0000 Received: from unknown (HELO coretech.co.nz) (10.0.10.28) by 0 with SMTP; 23 Jul 2004 00:05:15 -0000 Message-ID: <41005639.9040107@coretech.co.nz> Date: Fri, 23 Jul 2004 12:05:13 +1200 From: Mark Kirkwood 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: Simon Riggs Cc: Tom Lane , 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> <12173.1090527593@sss.pgh.pa.us> <1090540113.3057.17.camel@localhost.localdomain> In-Reply-To: <1090540113.3057.17.camel@localhost.localdomain> 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/261 X-Sequence-Number: 14329 I have tested the "cold" backup - and retested my previous scenarios using "hot" backup (just to be sure) . They all work AFAICS! cheers Mark Simon Riggs wrote: >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 > > >