Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id A1E98633BCD for ; Thu, 11 Feb 2010 09:51:18 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 33407-02-3 for ; Thu, 11 Feb 2010 13:51:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail128067.authsmtp.com (outmail128067.authsmtp.com [62.13.128.67]) by mail.postgresql.org (Postfix) with ESMTP id 5162F634647 for ; Thu, 11 Feb 2010 09:51:06 -0400 (AST) Received: from mail-c194.authsmtp.com (mail-c194.authsmtp.com [62.13.128.121]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id o1BDoxhS077619; Thu, 11 Feb 2010 13:50:59 GMT Received: from [10.0.1.26] (74-92-138-153-WashingtonDC.hfc.comcastbusiness.net [74.92.138.153]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id o1BDopcT051958; Thu, 11 Feb 2010 13:50:52 GMT Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL From: Simon Riggs To: Dimitri Fontaine Cc: Heikki Linnakangas , Fujii Masao , PostgreSQL-development In-Reply-To: <877hqjc2kk.fsf@hi-media-techno.com> References: <20100127152751.3B2047541B9@cvs.postgresql.org> <3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com> <4B726120.80007@enterprisedb.com> <1265884657.7341.1192.camel@ebony> <4B73F678.8070109@enterprisedb.com> <1265891248.7341.1346.camel@ebony> <4B73FB99.4080403@enterprisedb.com> <1265893599.7341.1454.camel@ebony> <877hqjc2kk.fsf@hi-media-techno.com> Content-Type: text/plain Date: Thu, 11 Feb 2010 13:50:50 +0000 Message-Id: <1265896250.7341.1627.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Server-Quench: 783e3d6b-1714-11df-80b9-0022640b883e X-Report-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksachtFaQRba1xT HGQLWlREUV57XGN/ bggfagFDa0hQXgZi TklMQU1XHAJ3AVJe B2xqDVkhEwVDeXd1 bQhrX3ldEkNydhN+ FkgGCGwBZGN9aWFL Bl1Qd1FdbQNKfB1D blAtXHsONCtlM3Bw LC8aFBMcBw5qYB5Y EEk+BnU3ZGc3IhMG fCVKBTo0BElXDwA6 LBFuMUIVGkobIw0p PEE/VEh6exQVDBFf GVxKHTRdNhEbSjYx HEs7R0MFDDpHQCFT SgEoL1dODyxOEhVx ICMA X-Authentic-SMTP: 61633235383639.1015:706/Kp X-AuthFastPath: 255 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=-2.599 tagged_above=-10 required=5 tests=AWL=0.000, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/856 X-Sequence-Number: 157199 On Thu, 2010-02-11 at 14:41 +0100, Dimitri Fontaine wrote: > Simon Riggs writes: > > If you were running pg_standby as the restore_command then this error > > wouldn't happen. So you need to explain why running pg_standby cannot > > solve your problem and why we must fix it by replicating code that has > > previously existed elsewhere. > > Let me try. > > pg_standby will not let the server get back to streaming replication > mode once it's done with driving the replay of all the WAL files > available in the archive, but will have the server sits there waiting > for the next file. > > The way we want that is implemented now is to have the server switch > back and forth between replaying from the archive and streaming from the > master. So we want the server to restore from the archive the same way > pg_standby used to, except that if the archive does not contain the next > WAL files, we want to get back to streaming. > > And the archive reading will resume at next network glitch. > > I think it's the reasonning, I hope it explains what you see happening. OK, thanks. One question then: how do we ensure that the archive does not grow too big? pg_standby cleans down the archive using %R. That function appears to not exist anymore. -- Simon Riggs www.2ndQuadrant.com