Received: from localhost (unknown [200.46.204.183])
	by developer.postgresql.org (Postfix) with ESMTP id 3958B2E003A
	for <pgsql-hackers-postgresql.org@developer.postgresql.org>;
	Tue, 13 May 2008 09:26:49 -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 40322-05
	for <pgsql-hackers-postgresql.org@developer.postgresql.org>;
	Tue, 13 May 2008 09:26:40 -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 148512E0031
	for <pgsql-hackers@postgresql.org>;
	Tue, 13 May 2008 09:26:42 -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 08:26:37 -0400
	id 0008BBE5.482988FD.00003F35
Message-ID: <482988FB.5070307@dunslane.net>
Date: Tue, 13 May 2008 08:26:35 -0400
From: Andrew Dunstan <andrew@dunslane.net>
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 <simon@2ndquadrant.com>
CC: Dave Page <dpage@pgadmin.org>, Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
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>
In-Reply-To: <482982DD.6060901@dunslane.net>
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/411
X-Sequence-Number: 118410


I wrote:
>
> However, we should probably make the behaviour switchable. If the 
> archive_command populating the archive_directory were rsync, for 
> example, this problem should not occur, because it copies to a temp 
> file, and then renames it, so we should never see an incomplete file 
> even though rsync also apparently preallocates space.
>
>

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.

I'm still not sure how to construct a test, though.

cheers

andrew