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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers