Re: Documentation Update: Document pg_start_backup checkpoint behavior - Mailing list pgsql-hackers

Michael Renner wrote:
> Hi,
>
> small patch for the documentation describing the current pg_start_backup
> checkpoint behavior as per
> http://archives.postgresql.org//pgsql-general/2008-09/msg01124.php .
>
> Should we note down a TODO to revisit the current checkpoint handling?
>
> best regards,
> Michael

> diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
> index 02545f1..6ea9488 100644
> --- a/doc/src/sgml/backup.sgml
> +++ b/doc/src/sgml/backup.sgml
> @@ -737,12 +737,8 @@ SELECT pg_start_backup('label');
>       (see the configuration parameter
>       <xref linkend="guc-checkpoint-completion-target">).  Usually
>       this is what you want because it minimizes the impact on query
> -     processing.  If you just want to start the backup as soon as
> -     possible, execute a <command>CHECKPOINT</> command
> -     (which performs a checkpoint as quickly as possible) and then
> -     immediately execute <function>pg_start_backup</>.  Then there
> -     will be very little for <function>pg_start_backup</>'s checkpoint
> -     to do, and it won't take long.
> +     processing.  Unfortunately it's currently not possible to expedite
> +     the checkpointing done by pg_start_backup.
>      </para>
>     </listitem>
>     <listitem>

I have combined the above patch with another change that reports a
checkpoint is taking place:

    test=> select pg_start_backup('12');
    NOTICE:  performing checkpoint
     pg_start_backup
    -----------------
     0/2000020
    (1 row)

Patch attached.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.123
diff -c -c -r2.123 backup.sgml
*** doc/src/sgml/backup.sgml    5 Mar 2009 19:50:03 -0000    2.123
--- doc/src/sgml/backup.sgml    3 Apr 2009 03:35:42 -0000
***************
*** 737,748 ****
       (see the configuration parameter
       <xref linkend="guc-checkpoint-completion-target">).  Usually
       this is what you want because it minimizes the impact on query
!      processing.  If you just want to start the backup as soon as
!      possible, execute a <command>CHECKPOINT</> command
!      (which performs a checkpoint as quickly as possible) and then
!      immediately execute <function>pg_start_backup</>.  Then there
!      will be very little for <function>pg_start_backup</>'s checkpoint
!      to do, and it won't take long.
      </para>
     </listitem>
     <listitem>
--- 737,744 ----
       (see the configuration parameter
       <xref linkend="guc-checkpoint-completion-target">).  Usually
       this is what you want because it minimizes the impact on query
!      processing.  Unfortunately it's currently not possible to expedite
!      the checkpointing done by pg_start_backup.
      </para>
     </listitem>
     <listitem>
Index: src/backend/access/transam/xlog.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.334
diff -c -c -r1.334 xlog.c
*** src/backend/access/transam/xlog.c    11 Mar 2009 23:19:24 -0000    1.334
--- src/backend/access/transam/xlog.c    3 Apr 2009 03:35:42 -0000
***************
*** 6977,6982 ****
--- 6977,6984 ----
      /* Ensure we release forcePageWrites if fail below */
      PG_ENSURE_ERROR_CLEANUP(pg_start_backup_callback, (Datum) 0);
      {
+         ereport(NOTICE,
+                 (errmsg("performing checkpoint")));
          /*
           * Force a CHECKPOINT.    Aside from being necessary to prevent torn
           * page problems, this guarantees that two successive backup runs will