Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 59AF9635099 for ; Thu, 11 Feb 2010 14:14:43 -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 93082-10 for ; Thu, 11 Feb 2010 18:14:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail137184.authsmtp.co.uk (outmail137184.authsmtp.co.uk [62.13.137.184]) by mail.postgresql.org (Postfix) with ESMTP id 2FA87632845 for ; Thu, 11 Feb 2010 14:14:31 -0400 (AST) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id o1BIEH6Y067659; Thu, 11 Feb 2010 18:14:17 GMT Received: from [192.168.1.8] (c-68-33-3-167.hsd1.md.comcast.net [68.33.3.167]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id o1BIEBmT028843; Thu, 11 Feb 2010 18:14:12 GMT Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL From: Simon Riggs To: Heikki Linnakangas Cc: Aidan Van Dyk , Fujii Masao , PostgreSQL-development In-Reply-To: <4B743E7D.5070603@enterprisedb.com> References: <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> <4B740613.5090004@enterprisedb.com> <20100211140118.GB14128@oak.highrise.ca> <4B74118C.30704@enterprisedb.com> <20100211144204.GC14128@oak.highrise.ca> <4B743E7D.5070603@enterprisedb.com> Content-Type: text/plain Date: Thu, 11 Feb 2010 18:11:01 +0000 Message-Id: <1265911861.7341.2266.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-Server-Quench: 41e6cb7b-1739-11df-ab46-001185d377ca X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksachtFaQRba1xT HGQLWlREUVV7WGd/ agkfaw1DYUlQXBtr Vk9WR1pVCwUmXh1z f2tsD31ydQ1OfH0+ bE5rXD5fXRF8JhR6 EFNVEm4PeGZhPDYC ARJccR5UcAJLdhoR aVd4ByJDAzANdhEY NiQQEgoKCH1lJXYd cSoqCHczfXomJAUJ DwgNBiwrTwUgTiY+ Zwc6I1gQFldZKUgo L1Y7OxoTNBkOCwtD GFxWBD4RPVQdXTtj RRlXRlIZCjxbTm9A AhBgJBJYHnRtcw4w X-Authentic-SMTP: 61633235383639.1000:706/Kp X-AuthFastPath: 255 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.11 tagged_above=-10 required=5 tests=BAYES_05=-1.11 X-Spam-Level: X-Archive-Number: 201002/910 X-Sequence-Number: 157253 On Thu, 2010-02-11 at 19:29 +0200, Heikki Linnakangas wrote: > Aidan Van Dyk wrote: > > * Heikki Linnakangas [100211 09:17]: > > > >> Yeah, if you're careful about that, then this change isn't required. But > >> pg_standby protects against that, so I think it'd be reasonable to have > >> the same level of protection built-in. It's not a lot of code. > > > > This 1 check isn't, but what about the rest of the things pg_standby > > does. How much functionality should we bring it? Ideally, "all" of it. > > Well, how about we bite the bullet then and add enough bells and > whistles to the backend that pg_standby really isn't needed anymore, and > remove it from contrib? > > Looking at the options to pg_standby, we're not missing much: You're attitude to this makes me laugh, and cry. Removing pg_standby can be done and if you manage it well, I would be happy. I laugh because it seems like you think I have some ego tied up in it. It's hardly my finest hour of coding, especially since I've not had the ability to improve it much before now. Not missing *much*?! I cry because you're so blase about missing one or two essential features that took years to put in place. Keeping pg_standby at least guarantees we can do something about it when we discover you didn't do a good enough job removing it. -- Simon Riggs www.2ndQuadrant.com