Josh Berkus <j...@agliodbs.com> writes:
>> pg_stop_backup() doesn't complete until all the WAL segments needed to
>> restore from the backup are archived. If archive_command is failing,
>> that never happens.
> OK, so we need a way out of that cycle if the user is issuing
> pg_stop_backup because they *already know* that archive_command is
> failing. Right now, there's no way out other than a fast shutdown,
> which is a bit user-hostile.
The pg_abort_backup() operation previously proposed seems like the only
workable compromise. Simon is quite right to not want pg_stop_backup()
to behave in a way that could contribute to data loss; but on the other
hand there needs to be some clear way to get the system out of that
state at need.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
