Re: odd output in restore mode

Simon Riggs wrote:
> On Tue, 2008-05-13 at 08:42 +0100, Dave Page wrote:
>
>> On Tue, May 13, 2008 at 2:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>
>>>
>>>> Simon Riggs wrote:
>>>>
>>> >> Well, the patch was rejected long ago, not sure why its in this
>>> >> commitfest. But its an open issue on the Windows port.
>>>
>>> > Surely the right fix is to use the recently implemented
>>> > pgwin32_safestat() (if we aren't already - I suspect we probably are)
>>> > and remove the kluge in pg_standby.c.
>>>
>>> I think the open issue is how to know whether pgwin32_safestat fixes the
>>> problem that the kluge tried to work around.
>>>
>> Per the comments on the commitfest page, I don't believe it is.
>> pgwin32_safestat fixes a bug in which stat() returns stale information
>> (if memory serves). The hack in pg_standby was added because copy in
>> Windows appears to preallocate the required space for the file it's
>> copying, thus checking the file size to verify that the copy has
>> completed is not a valid test.
>>
>
> Could somebody suggest and test an improvement to the Windows code, to
> fix the kluge?
>
>

Given what Dave says, I'm not sure there is an easy one, at least
without a lot of testing. Greg Stark's suggestion might or might not work.

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.

We should also document it better in the code, along the lines of Dave's
comment above.

cheers

andrew