Hackers,
Since Gabrielle has improved archiving with pg_stat_archiver in 9.4, I'd
like to go further and improve the usability of pg_stop_backup().
However, based on my IRC discussion with Vik, there might not be
consensus on what the right behavior *should* be. This is for 9.5, of
course.
Currently, if archive_command is failing, pg_stop_backup() will hang
forever. The only way to figure out what's wrong with pg_stop_backup()
is to tail the PostgreSQL logs. This is difficult for users to
troubleshoot, and strongly resists any kind of automation.
Yes, we can work around this by setting statement_timeout, but that has
two issues (a) the user has to remember to do it before the problem
occurs, and (b) it won't differentiate between archive failure and other
reasons it might time out.
As such, I propose that pg_stop_backup() should error with an
appropriate error message ("Could not archive WAL segments") after three
archiving attempts. We could also add an optional parameter to raise
the number of attempts from the default of three.
An alternative, if we were doing this from scratch, would be for
pg_stop_backup to return false or -1 or something if it couldn't
archive; there are reasons why a user might not care that
archive_command was failing (shared storage comes to mind). However,
that would be a surprising break with backwards compatability, since
currently users don't check the result value of pg_stop_backup().
Thoughts?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
