Re: pg_stop_backup does not complete

Looks like we arrived at the best solution here. I don't think it was
clear to users that pg_stop_backup() was issuing an archive_command and
hence they wouldn't be likely to understand the delay or correct a
problem. This gives them the information they need at the time they
need it.

---------------------------------------------------------------------------

Tom Lane wrote:
> Greg Smith <greg(at)2ndquadrant(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)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. +