Greg,
> I expect for your particular bad situation, you can replace the
> archive_command with a corrected one, use "pg_ctl reload" to send a
> SIGHUP to make that fix active, and escape from this. That's the only
> right way out of this situation. You can't just abort a backup someone
> has asked for just because archives are failing and allow the server to
> shutdown cleanly in this situation. That's the wrong thing to do for
> production setups; the last thing you want for a system with archiving
> issues is to be stopped normally if it's interfering with an explicit
> admin requested backup.
Yeah, I can see that for large production setups with multiple staff.
We also need something newbie-friendly (and friendly to the large number
of users we have where the DBA/Sysadmin is just the most skilled web
developer) though. The above procedure is far too complex for someone
who is "just trying out" PostgreSQL as a replacement for MySQL, and if
recent conferences are anything to go by, we're about to have several
thousand such users.
BTW, please stop treating this issue as something which happens "only to
Josh". I wouldn't be raising it if it weren't a natural circumstance
which anyone who is trying PostgreSQL with HS/SR for the first time,
with no experience with Warm Standby, would get into. Such new users
are *likely* to get archive_command wrong, and likely to want to start
over when they do. If we make that painful for them, they'll just
switch to MySQL or CouchDB instead.
Thing is, if archive_command is failing, then the backup is useless
regardless until it's fixed. And sending the archives to /dev/null (the
fix you're essentially recommending above) doesn't make the backup any
more useful. So I'm seeing pg_abort_backup(), which also produces a
markers which prevent the backup from loading, as an improvement on
current UI.
--Josh Berkus
