Michael Wallace
Michael Wallace
@emamuse86 thanks for reporting this issue - can you share the version of Barman you are using? The only scenario I can of which would result in what you describe...
I've spent a bit of time thinking this one through - ultimately I think the proposed change is fine, but I'm a bit concerned because we'd be changing some undocumented...
To summarize, the change here is going to be: * Barman will use `wait_for_archive=FALSE` when calling `pg_stop_backup`. * This means the backup will finish whether or not PostgreSQL considers the...
After a lot of testing and discussion the workaround proposed in PR #580 is being abandoned in favour of #596.
The underlying issue here should be resolved by #596.
Platforms for which we currently package using python2: * EL/CentOS 7 * SLES 12 * ~~Debian 9~~ (this is no longer supported) The SLES 12 situation is as follows: *...
Thanks for reporting the issue Mrudula - the immediate cause is that some of the fields in the backup.info metadata file (end_offset, end_time, end_wal and end_xlog) have values of `None`...
That's great - at least barman can continue functioning now. I've taken a look at barman 2.7 and the current version of barman (2.19) to determine how the `backup.info` file...
I suspect the failure to write the backup label is related to the first error: `ERROR: The backup has failed starting backup`. Could you post the full log from the...
Unfortunately I think the original exception is getting buried because of the exception which occurs when attempting to write the backup label in the `finally` block - this causes a...