> That's not what I said to do first. If it's possible to fix your
> archive_command, and it never returned bad "I'm saying success but I
> didn't really do the right thing" information to the server--it just
> failed--this situation is completely recoverable with no damage to the
> backup. Just fix the archive_command, reload the configuration, and the
> queue of archived files will flow and eventually your consistent backup
> completes. This it the only behavior someone who is trying to recover
> from a mistake in production is likely to find acceptable, and as Simon
> has pointed out that is what the current situation is optimized for.
Right. I'm pointing out that production and "trying out 9.0 for the
first time" are actually different circumstances, and we need to be able
to handle both gracefully. Since, if people have a bad experience
trying it out for the first time, we'll never *get* to production.
> As far your comment about treating this like it's a problem specific to
> you, did you miss the part where I pointed out I was just expressing
> concerns about poor visiblity into this area ("what is the archiver
> doing?") recently? I'm well aware this path is full of difficult to
> escape from holes. We just need to be careful not do something that
> screws over production users in the name of reducing the learning curve.
I think Tom's idea is minimally intrusive, and deals with the central
problem, which is one of UI and visibility as you assessed.
--Josh Berkus