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: Fujii Masao on 24 Feb 2010 21:07 On Thu, Feb 25, 2010 at 10:52 AM, Tom Lane <tgl(a)sss.pgh.pa.us> 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. > Although Greg is correct that a NOTICE wouldn't be logged at default > log levels, lots of people don't use that default. Comments? I don't want that immediate NOTICE message, which sounds like a noise. Delaying it or changing the log level to DEBUG work for me. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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:15 > I don't want that immediate NOTICE message, which sounds like a noise. > Delaying it or changing the log level to DEBUG work for me. Problem is that a new user won't be seeing DEBUG messages by default. This issue is all about new user experience. Alternatively, we could move the time of the first "waiting for archive" message up, but that seems misleading. --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 21:19 Greg Smith <greg(a)2ndquadrant.com> writes: > Tom Lane wrote: >> The value of the HINT I think would be to make them (a) not afraid to >> hit control-C and (b) aware of the fact that their archiver has got >> a problem. >> > Agreed on both points. Patch attached that implements something similar > to Josh's wording, tweaking the original warning too. OK, everyone likes the immediate NOTICE. I did a bit of copy-editing and committed the attached version. regards, tom lane Index: xlog.c =================================================================== RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v retrieving revision 1.377 diff -c -r1.377 xlog.c *** xlog.c 19 Feb 2010 10:51:03 -0000 1.377 --- xlog.c 25 Feb 2010 02:15:49 -0000 *************** *** 8132,8138 **** * * We wait forever, since archive_command is supposed to work and we * assume the admin wanted his backup to work completely. If you don't ! * wish to wait, you can set statement_timeout. */ XLByteToPrevSeg(stoppoint, _logId, _logSeg); XLogFileName(lastxlogfilename, ThisTimeLineID, _logId, _logSeg); --- 8132,8139 ---- * * We wait forever, since archive_command is supposed to work and we * assume the admin wanted his backup to work completely. If you don't ! * wish to wait, you can set statement_timeout. Also, some notices ! * are issued to clue in anyone who might be doing this interactively. */ XLByteToPrevSeg(stoppoint, _logId, _logSeg); XLogFileName(lastxlogfilename, ThisTimeLineID, _logId, _logSeg); *************** *** 8141,8146 **** --- 8142,8150 ---- BackupHistoryFileName(histfilename, ThisTimeLineID, _logId, _logSeg, startpoint.xrecoff % XLogSegSize); + ereport(NOTICE, + (errmsg("pg_stop_backup cleanup done, waiting for required WAL segments to be archived"))); + seconds_before_warning = 60; waits = 0; *************** *** 8155,8162 **** { seconds_before_warning *= 2; /* This wraps in >10 years... */ ereport(WARNING, ! (errmsg("pg_stop_backup still waiting for archive to complete (%d seconds elapsed)", ! waits))); } } --- 8159,8169 ---- { seconds_before_warning *= 2; /* This wraps in >10 years... */ ereport(WARNING, ! (errmsg("pg_stop_backup still waiting for all required WAL segments to be archived (%d seconds elapsed)", ! waits), ! errhint("Check that your archive_command is executing properly. " ! "pg_stop_backup can be cancelled safely, " ! "but the database backup will not be usable without all the WAL segments."))); } } -- 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 Stark on 25 Feb 2010 10:08 On Wed, Feb 24, 2010 at 11:14 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > > Right. I'm pointing out that production and "trying out 9.0 for the > first time" are actually different circumstances, and we need to be able > to handle both gracefully. Since, if people have a bad experience > trying it out for the first time, we'll never *get* to production. Fwiw if it's not clear what's going on when you're trying out something carefully for the first time it's 10x worse if you're stuck in a situation like this when you have people breathing down your neck yelling about how they're losing money for every second you're down. In an ideal world it would be best if pg_stop_backup could actually print the error status of the archiving command. Is there any way for it to get ahold of the fact that the archiving is failing? And do we have closure on whether a "fast" shutdown is hanging? Or was that actually a smart shutdown? Perhaps "smart" shutdown needs to print out what it's waiting on periodically as well, and suggest a fast shutdown to abort those transactions. -- greg -- 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: Bruce Momjian on 25 Feb 2010 11:37
Heikki Linnakangas wrote: > Josh Berkus wrote: > > OK, can you go through the reasons why pg_stop_backup would not > > complete? > > 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. Yes, very old behavior allowed people to think they had a full backup when the WAL files needed were not all archived, which was a bad thing. Thankfully no one reported catastrophic failure from the old behavior. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |