On Fri, Apr 10, 2015 at 1:48 PM,  <[email protected]> wrote:
> 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]> 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?
>>
>> Secondly, would you consider trying v0.8? (Alternatively: nail the bug
>> by inspection in v0.7, if you feel up for it)
>
>
>
> unfortunately i am seeing the same problem with v0.8.0

Thanks for confirming that.  It does help triangulate a problem as
that code got whacked around quite a bit.

Can you try the branch/patch here?
https://github.com/fdr/wal-e/tree/delete-on-error

-- 
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