Re: odd output in restore mode - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: odd output in restore mode
Date
Msg-id 1210657475.29684.280.camel@ebony.site
Whole thread Raw
In response to Re: odd output in restore mode  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Mon, 2008-05-12 at 23:03 -0400, Andrew Dunstan wrote:
> Tom Lane 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.
> >
> Well, I think we need to consider quite a number of scenarios. The 
> archive directory could be local, on a remote Windows machine, or on a 
> remote Samba server. The archive file could be copied by Windows copy, 
> or Unix cp, or scp, or rsync, among others.
> 
> I'd like to know the setup that was found to produce the error, to start 
> with.

It's a race condition, not a deterministic bug with recreatable
conditions. My understanding is the current code was introduced to work
around the implementation of stat on Windows which says the filesize is
correct even while it is still copying it. The 1sec delay fixed that but
is clearly not a foolproof fix and introduces a delay also, which was
the original complaint.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: Syntax decisions for pl/pgsql RAISE extension
Next
From: "Josh Tolley"
Date:
Subject: Problem returning strings with pgsql 8.3.x