pg_stop_backup does not complete
in [PgSql]
|
Prev: [HACKERS] pg_stop_backup does not complete
Next: [PATCH] backend: compare word-at-a-time in bcTruelen
From: Josh Berkus on 24 Feb 2010 20:47 On 2/24/10 5:36 PM, Greg Smith wrote: > gsmith=# select pg_stop_backup(); > NOTICE: pg_stop_backup cleanup done, waiting for required segments to > archive > WARNING: pg_stop_backup still waiting for all required segments to > archive (60 seconds elapsed) > HINT: Confirm your archive_command is executing successfully. > pg_stop_backup can be aborted safely, but the resulting backup will not > be usable. > ^CCancel request sent > ERROR: canceling statement due to user request This looks really good, thanks! > Does this solve the logging side of this? You can still make a case for > a more forceful pg_stop_backup, this seems to at least remove much of > the mystery and frustration from the whole exercise. This patch plus a > little documentation suggesting how to recover from this issue might be > enough. Yeah, the concern is user-friendliness. As Simon points out, allowing pg_stop_backup to abort would have other unexpected-results issues. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 24 Feb 2010 20:52 Josh Berkus <josh(a)agliodbs.com> writes: > On 2/24/10 5:36 PM, Greg Smith wrote: >> gsmith=# select pg_stop_backup(); >> NOTICE: pg_stop_backup cleanup done, waiting for required segments to >> archive >> WARNING: pg_stop_backup still waiting for all required segments to >> archive (60 seconds elapsed) >> HINT: Confirm your archive_command is executing successfully. >> pg_stop_backup can be aborted safely, but the resulting backup will not >> be usable. >> ^CCancel request sent >> ERROR: canceling statement due to user request > This looks really good, thanks! The one thing I'm undecided about is whether we want the immediate NOTICE, as opposed to dialing down the time till the first WARNING to something like 5 or 10 seconds. I think the main argument for the latter approach would be to avoid log-spam in normal operation. Although Greg is correct that a NOTICE wouldn't be logged at default log levels, lots of people don't use that default. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 24 Feb 2010 20:57 On Wed, Feb 24, 2010 at 08:52:28PM -0500, Tom Lane wrote: > Josh Berkus <josh(a)agliodbs.com> writes: > > On 2/24/10 5:36 PM, Greg Smith wrote: > >> gsmith=# select pg_stop_backup(); > >> NOTICE: pg_stop_backup cleanup done, waiting for required segments to > >> archive > >> WARNING: pg_stop_backup still waiting for all required segments to > >> archive (60 seconds elapsed) > >> HINT: Confirm your archive_command is executing successfully. > >> pg_stop_backup can be aborted safely, but the resulting backup will not > >> be usable. > >> ^CCancel request sent > >> ERROR: canceling statement due to user request > > > This looks really good, thanks! > > The one thing I'm undecided about is whether we want the immediate > NOTICE, as opposed to dialing down the time till the first WARNING > to something like 5 or 10 seconds. I think the main argument for > the latter approach would be to avoid log-spam in normal operation. > Although Greg is correct that a NOTICE wouldn't be logged at default > log levels, lots of people don't use that default. Comments? As I see it, the clarity concern trumps the log spam one. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Smith on 24 Feb 2010 20:58 Tom Lane wrote: > The one thing I'm undecided about is whether we want the immediate > NOTICE, as opposed to dialing down the time till the first WARNING > to something like 5 or 10 seconds. I think the main argument for the > latter approach would be to avoid log-spam in normal operation I though about that for a minute, but didn't think pg_stop_backup is a common enough operation that anyone will complain that it's a little more verbose in its logging now. I know when I was new to this, I used to wonder just what it was busy doing just after executing this command when it hung there for a while sometimes, and would have welcomed this extra bit of detail--preferably immediately, not even after a 5 or 10 second delay. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 24 Feb 2010 21:01
On 2/24/10 5:58 PM, Greg Smith wrote: > > I though about that for a minute, but didn't think pg_stop_backup is a > common enough operation that anyone will complain that it's a little > more verbose in its logging now. I know when I was new to this, I used > to wonder just what it was busy doing just after executing this command > when it hung there for a while sometimes, and would have welcomed this > extra bit of detail--preferably immediately, not even after a 5 or 10 > second delay. +1 --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |