From: Andrew Dunstan <andrew@dunslane.net>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Dave Page <dpage@pgadmin.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: odd output in restore mode
Date: Tue, 13 May 2008 08:00:29 -0400
Message-ID: <482982DD.6060901@dunslane.net> (raw)
In-Reply-To: <1210667576.29684.283.camel@ebony.site>
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>
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@sss.pgh.pa.us> wrote:
>>
>>> Andrew Dunstan <andrew@dunslane.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: andrew@dunslane.net, simon@2ndquadrant.com, dpage@pgadmin.org, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: odd output in restore mode
In-Reply-To: <482982DD.6060901@dunslane.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox