Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 63F7837BFEE for ; Tue, 7 Oct 2008 05:15:59 -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 20680-09 for ; Tue, 7 Oct 2008 05:15:49 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail136042.authsmtp.net (outmail136042.authsmtp.net [62.13.136.42]) by postgresql.org (Postfix) with ESMTP id 26F4437BAC0 for ; Tue, 7 Oct 2008 05:15:48 -0300 (ADT) Received: from mail-c188.authsmtp.com (mail-c188.authsmtp.com [62.13.128.25]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m978FfW8058010; Tue, 7 Oct 2008 09:15:41 +0100 (BST) Received: from [192.168.0.3] (85-211-69-124.dyn.gotadsl.co.uk [85.211.69.124]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m978FeG5025673; Tue, 7 Oct 2008 09:15:40 +0100 (BST) Subject: Re: [PATCHES] Infrastructure changes for recovery From: Simon Riggs To: Andrew Dunstan Cc: Tom Lane , pgsql-hackers In-Reply-To: <48E5544B.5050103@dunslane.net> 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> <1222985488.4445.1625.camel@ebony.2ndQuadrant> <48E5544B.5050103@dunslane.net> Content-Type: text/plain Date: Tue, 07 Oct 2008 09:17:25 +0100 Message-Id: <1223367445.4747.105.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: 21563c7f-9448-11dd-aecc-001871e930f4 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFaAJbYlpF HGQLW1xEUFR7WGZ/ bwofZQBDYEtPQQNj TklLRk1QEQdtHhxP WxcZWm8nAABGent2 YkUsXXFcVQp4dEN7 QR1TQ3APYWNodWEe BBRFJlYHIx5Kfh5N bVEqXXANN2FJBC9q VzwLFgwaHRhkHWxm YigmDn8oenNDPzgy XRkZAS8yFlEYXSh7 JBwvLFERBw4fNV96 K1YqXkwVKQ56 X-Authentic-SMTP: 61633235383639.cat.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: 200810/246 X-Sequence-Number: 125263 On Thu, 2008-10-02 at 19:07 -0400, Andrew Dunstan wrote: > Simon Riggs wrote: > > Just seen this patch has been bounced into November CommitFest, even > > though the new patch fixes all of the concerns raised. > > > > I'm concerned that this is going to make the final Hot Standby patch > > fairly large, which will make it even harder to review, test and > > generally get accepted. > > > > What's the best way to make this easier for you/others to review? > The fact that it's been put on the November list doesn't mean it can't > be reviewed and committed before then. But that seems unlikely to be the case. A patch specifically marked as "required for other work" has been delayed by more than 5 weeks on queue and nobody was ever assigned to review it. That was exactly the problem CommitFests were supposed to resolve and from my perspective this is a systemic failure. If I had submitted the patch a month late it wouldn't have got reviewed any earlier, yet many people would cry foul (why?). The current system means I have to code up to the deadline, officially do nothing for a month, then respond within hours to code reviews or have the patch rejected for another month. It works great for minor patches, but its simply not working for bigger features. It's just not possible to be fully available to respond to reviews, yet at the same time not able to work more than about 25% of the development calendar. Luckily Tom reviewed it, but with no commit and no guidance on how to proceed this still leaves me in a difficult position. I'm forced now to leave much of this code behind, since I cannot now complete Hot Standby at the same time as having bgwriter active during recovery, if that code is at risk of causing the whole thing to be rejected. Are the two together a risk? No. Is developing them together harder? Yes. Do *I* trust my own code? Yes, but its reviewers that count. Is it a good thing for Postgres to leave this code behind? Probably not. Can I add it later? Maybe. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support