Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 96F4D64FCC0; Sat, 2 Aug 2008 11:27:49 -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 52597-08; Sat, 2 Aug 2008 11:27:37 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from alexis.jtlnet.com (alexis.jtlnet.com [69.36.9.81]) by postgresql.org (Postfix) with ESMTP id 6F983650054; Sat, 2 Aug 2008 11:27:42 -0300 (ADT) Received: from [192.168.10.103] (cpe-075-177-154-079.nc.res.rr.com [::ffff:75.177.154.79]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by alexis.jtlnet.com with esmtp; Sat, 02 Aug 2008 10:20:38 -0400 id 0008BBEC.48946D37.000001FD Message-ID: <48946EC9.1010000@dunslane.net> Date: Sat, 02 Aug 2008 10:27:21 -0400 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text SeaMonkey/1.0.9 MIME-Version: 1.0 To: Simon Riggs CC: Tom Lane , Heikki Linnakangas , Martin Zaun , Greg Smith , Kevin Grittner , Bruce Momjian , Dave Page , PostgreSQL-development , List pgsql-patches Subject: Re: [HACKERS]odd output in restore mode References: <200807011520.m61FKhZ20311@momjian.us> <48867904.9090001@sun.com> <1216810783.3894.602.camel@ebony.2ndQuadrant> <48877AC0.7070603@enterprisedb.com> <48873C7E.EE98.0025.0@wicourts.gov> <488DEE79.4010004@dunslane.net> <488F28CB.8000201@enterprisedb.com> <48909C16.6070401@sun.com> <4891E2BC.203@enterprisedb.com> <9981.1217521958@sss.pgh.pa.us> <1217671669.3934.119.camel@ebony.t-mobile.de.> In-Reply-To: <1217671669.3934.119.camel@ebony.t-mobile.de.> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 200808/7 X-Sequence-Number: 6983 Simon Riggs wrote: > Well, this is a strange conclusion, leaving me slightly bemused. > > The discussion between Andrew and I at PGcon concluded that we would > * document which other tools to use > * remove the delay > > Now we have rejected the patch which does that, but then re-requested > the exact same thing again. > > The patch interprets "remove the delay" as "remove the delay in a way > which will not screw up existing users of pg_standby when they upgrade". > Doing that requires us to have a configurable delay, which defaults to > the current behaviour, but that can be set to zero (the recommended > way). Which is what the patch implements. > > Andrew, Heikki: ISTM its time to just make the changes yourselves. This > is just going round and round to no benefit. This doesn't warrant such a > long discussion and review process. > You ought to know by now that the length and ferocity of the discussion bears no relation at all to the importance of the subject ;-) Personally, I think it's reasonable to provide the delay as long as it's switchable, although I would have preferred zero to be the default. If we remove it altogether then we force bigger changes on people who are currently using Windows copy. But I can live with that since changing their archive_command is the better path by far anyway, either to use Gnu cp or the copy / rename trick. cheers andrew