Currently pg_stop_backup() will wait for all WAL to be archived before
returning. If there is a problem with the archive command or a large
backlog it may not return for a very long time (if ever). Backup
software is faced with the choice of cancelling the query and hoping the
stop backup record was written or waiting indefinitely.
The purpose of this patch is to make waiting for archive optional, with
the default being the current behavior, i.e., to wait for all WAL to be
archived. This functionality is already used internally by
pg_basebackup, so the only real change is to expose it through the
pg_stop_backup() function.
I wasn't sure where, if anywhere, to put tests (the underlying
functionality is tested in the pg_basebackup TAP tests). test/recovery
and bin/pg_basebackup did not seem like appropriate places and the
pg_regress tests are not capable enough. It seems like a new
test/backup suite would be a good idea but I wanted to get some feedback
before proceeding in that direction.
I also marked the pg_stop_* functions as parallel restricted, the same
as pg_start_backup(). Previously they were parallel safe which I don't
believe is accurate for the non-exclusive version at the very least,
since it is tied to a particular backend.
The patch applies cleanly on 30df93f but will be broken (and easily
fixed) by any cat version bump in later commits.
--
-David
david@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers