Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id B8F4737BA28; Sun, 28 Sep 2008 21:53:09 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 77832-03; Sun, 28 Sep 2008 21:53:06 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail136191.authsmtp.com (outmail136191.authsmtp.com [62.13.136.191]) by postgresql.org (Postfix) with ESMTP id 7ABB337B9B1; Sun, 28 Sep 2008 21:53:06 -0300 (ADT) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m8T0r3aZ015635; Mon, 29 Sep 2008 01:53:03 +0100 (BST) Received: from [192.168.0.3] (85-211-71-126.dyn.gotadsl.co.uk [85.211.71.126]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m8T0r2qC010661; Mon, 29 Sep 2008 01:53:02 +0100 (BST) Subject: Re: [PATCHES] Infrastructure changes for recovery From: Simon Riggs To: Tom Lane Cc: List pgsql-patches , pgsql-hackers In-Reply-To: <9794.1222624945@sss.pgh.pa.us> References: <1218109459.4549.423.camel@ebony.2ndQuadrant> <1220213074.4371.173.camel@ebony.2ndQuadrant> <1905.1220895241@sss.pgh.pa.us> <1221080797.3913.768.camel@ebony.2ndQuadrant> <15776.1221594318@sss.pgh.pa.us> <1221725145.3913.2315.camel@ebony.2ndQuadrant> <16992.1221743196@sss.pgh.pa.us> <1221745847.3913.2408.camel@ebony.2ndQuadrant> <18549.1221746983@sss.pgh.pa.us> <1222121161.4445.248.camel@ebony.2ndQuadrant> <1222184541.4445.400.camel@ebony.2ndQuadrant> <28973.1222381719@sss.pgh.pa.us> <1222424415.4445.917.camel@ebony.2ndQuadrant> <9794.1222624945@sss.pgh.pa.us> Content-Type: text/plain Date: Mon, 29 Sep 2008 01:54:19 +0100 Message-Id: <1222649659.4445.1061.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: f85606b2-8dc0-11dd-8155-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFagxbflxB HGQLW1xEUFx7XGB/ awkfZQBDYEtPQQJr TklLRE1QEQdtHhxP WxZ6UltwNnZGeX52 Y0csXHNcWQosfUN7 QkgGF3AOMTRgdWEe BBRFfwJRdR5Kfh5E YlUrV3QKMjRJBC9q VzwLFgwaHRhkHWxm YigmDn8oenNDPzgy XRkZAS8yFlEYXSh7 JBwvLFERBw4fNV96 K1YqXkwVKQ56 X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:1378/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/1775 X-Sequence-Number: 124904 On Sun, 2008-09-28 at 14:02 -0400, Tom Lane wrote: > It does nothing AFAICS for the > problem that when restarting archive recovery from a restartpoint, > it's not clear when it is safe to start letting in backends. You need > to get past the highest LSN that has made it out to disk, and there is > no good way to know what that is. > > Unless we can get past this problem the whole thing seems a bit dead > in > the water :-( I agree the importance of your a problem but don't fully understand the circumstances under which you see a problem arising. AFAICS when we set minRecoveryLoc we *never* unset it. It's recorded in the controlfile, so whenever we restart we can see that it has been set previously and now we are beyond it. So if we crash during recovery and then restart *after* we reached minRecoveryLoc then we resume in safe mode almost immediately. If we crash during recovery before we reached minRecoveryLoc then we continue until we find it. There is a loophole, as described on separate post, but that can be plugged by offering explicit setting of the minRecoveryLoc from recovery.conf. Most people use pg_start_backup() so do not experience the need for that. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support