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

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@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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.comPG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard
drive,Christ can be your backup. +