Re: pg_stop_backup does not complete - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_stop_backup does not complete
Date
Msg-id 608.1267048320@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_stop_backup does not complete  (Josh Berkus <josh@agliodbs.com>)
Responses Re: pg_stop_backup does not complete  (Josh Berkus <josh@agliodbs.com>)
Re: pg_stop_backup does not complete  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> 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.

On reflection I'm not sure what pg_abort_backup would do for you.
As Heikki points out, by the time the user has realized that
pg_stop_backup() is not completing, it's *already done* all of the
state changes it's going to make.  There is no way to take the
backup-complete WAL entry out of the WAL stream; it's already in there
and there's probably ordinary entries after it by now.  Having a
oh-the-backup-failed-after-all entry somewhere downstream of that is
entirely useless; the more so because by the time anything could *see*
such an entry, the problem would have been resolved, since the problem
is exactly not having gotten the WAL stream out to the archive.

Before you could enter pg_abort_backup you'd have to control-C out of
the pg_stop_backup call, and that action already accomplishes the only
thing pg_abort_backup could do for you.

So what I am thinking is that this is really just a minor bit of user
unfriendliness in pg_stop_backup.  We should address it with one or
both of these changes:

* emit a NOTICE as soon as pg_stop_backup's actual work is done and
it's starting to wait for the archiver (or maybe after it's waited
for a few seconds, but much less than the present 60).

* extend the existing WARNING (and the NOTICE too if we elect to have
one) with a HINT message explicitly saying that you can cancel the
wait but thus-and-such consequences might ensue.

Both of these things would only be helpful when using client software
that shows you received notices promptly.  psql is okay, but maybe
pgAdmin and other tools would need some further work.  There is not
much we can do about that in the core project though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gokulakannan Somasundaram
Date:
Subject: Re: A thought on Index Organized Tables
Next
From: Simon Riggs
Date:
Subject: Re: pg_stop_backup does not complete