Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id E58732E003F for ; Sun, 18 May 2008 09:38:23 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 30192-08 for ; Sun, 18 May 2008 09:38:12 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from alexis.jtlnet.com (alexis.jtlnet.com [69.36.9.81]) by developer.postgresql.org (Postfix) with ESMTP id C9A1F2E002F for ; Sun, 18 May 2008 09:38:16 -0300 (ADT) Received: from [192.168.10.103] (cpe-075-177-177-228.nc.res.rr.com [::ffff:75.177.177.228]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by alexis.jtlnet.com with esmtp; Sun, 18 May 2008 08:37:41 -0400 id 00097B51.48302315.00002D26 Message-ID: <48302334.2020906@dunslane.net> Date: Sun, 18 May 2008 08:38:12 -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: Dave Page CC: Alvaro Herrera , Simon Riggs , Tom Lane , PostgreSQL-development Subject: Re: odd output in restore mode References: <4828CB9D.7070102@dunslane.net> <4828EBCB.6010004@dunslane.net> <6489.1210642738@sss.pgh.pa.us> <937d27e10805130042m35584e2fk79dc3490173d3bd4@mail.gmail.com> <1210667576.29684.283.camel@ebony.site> <482982DD.6060901@dunslane.net> <482988FB.5070307@dunslane.net> <20080513150852.GD6966@alvh.no-ip.org> <4829BC66.4020602@dunslane.net> <20080513161130.GJ6966@alvh.no-ip.org> <937d27e10805130915n7fa68737ka573d43b516f7bc0@mail.gmail.com> In-Reply-To: <937d27e10805130915n7fa68737ka573d43b516f7bc0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/592 X-Sequence-Number: 118591 Dave Page wrote: > On Tue, May 13, 2008 at 5:11 PM, Alvaro Herrera > wrote: > >> Andrew Dunstan wrote: >> >> > I would be very surprised if xcopy did not exhibit the same >> > preallocating behaviour as copy. >> >> I, on the other hand, would not say anything until someone tried it, and >> then wouldn't be surprised if it behaved either way :-) >> > > It pre-allocates the space as copy does. And yes, I did test :-p > > > Dave, I don't know how you tested, but could you please repeat the test with GnuWin32's cp.exe? If it doesn't preallocate the space then I think our way forward is reasonably clear: . we recommend its use for Windows archive_command settings . we provide the delay kluge as switchable behaviour on Windows instead of having it always on. cheers andrew