Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 6C6AF2E0124 for ; Tue, 13 May 2008 13:09:57 -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 95760-02-2 for ; Tue, 13 May 2008 13:09:39 -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 0F3492E00F5 for ; Tue, 13 May 2008 13:06:03 -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; Tue, 13 May 2008 12:05:57 -0400 id 0008BBA8.4829BC65.00005C73 Message-ID: <4829BC66.4020602@dunslane.net> Date: Tue, 13 May 2008 12:05:58 -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: Alvaro Herrera CC: Simon Riggs , Dave Page , Tom Lane , PostgreSQL-development Subject: Re: odd output in restore mode References: <4828AF1D.7060405@dunslane.net> <1210630440.29684.249.camel@ebony.site> <4828CB9D.7070102@dunslane.net> <1210635473.29684.268.camel@ebony.site> <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> In-Reply-To: <20080513150852.GD6966@alvh.no-ip.org> 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/429 X-Sequence-Number: 118428 Alvaro Herrera wrote: > Andrew Dunstan wrote: > > >> Another and probably simpler thing to try would be the GnuWin32 version >> of cp. If we can verify that it behaves itself, we should probably >> recommend it for use in archive_command instead of the native Windows >> copy. >> > > Perhaps use xcopy, which should be more ubiquitous? > > I would be very surprised if xcopy did not exhibit the same preallocating behaviour as copy. cheers andrew