On Friday, April 10, 2015 at 12:49:47 PM UTC-4, Daniel Farina wrote:
>
> On Fri, Apr 10, 2015 at 9:12 AM,  <[email protected] <javascript:>> 
> wrote: 
> > I've run into a problem trying to do a point-in-time recovery that 
> appears 
> > to be specific to OpenStack using wal-e version 0.7.3. wal-e appears to 
> be 
> > restoring non-existent .history files even though the wal-fetch is 
> failing. 
> > as a result, it continues to increment and try and fetch the next 
> .history 
> > files ad infinitum (e.g. 00000002.history, 00000003.history, 
> > 00000004.history and on and on and on) since the DB "thinks" that the 
> > .history files are being restored when the are really not. 
> > 
> > everything works ok with AWS, stopping after the first failure with no 
> > message noting "restored log file "00000002.history" from archive" as is 
> > happening (and shown and bolded below) with OpenStack. 
>
> Hum. People have definitely noted some bugs where failures can result 
> in empty files being left behind by WAL-E.  I thought all of those 
> were in v0.8 -- and fixed -- but maybe not this one. 
>
> Is there a way you can identify if an empty file by the name 
> "00000002.history" (or whatever bogus file is "thought" to exist) is 
> in pg_xlog while this bug is occuring? 
>
>
actually i was mistaken in my previous reply (i accidentally looked at the 
wrong machine). i just retested and there is no empty file in pg_xlog while 
this bug is occurring.
 

> Secondly, would you consider trying v0.8? (Alternatively: nail the bug 
> by inspection in v0.7, if you feel up for it) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"wal-e" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to