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 <[email protected]> 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
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
