1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00

Add an optional parameter to pg_start_backup() that specifies whether to do

the checkpoint in immediate or lazy mode.  This is to address complaints
that pg_start_backup() takes a long time even when there's no need to minimize
its I/O consumption.
This commit is contained in:
Tom Lane
2009-04-07 00:31:26 +00:00
parent 80df9c49af
commit 387060951e
6 changed files with 54 additions and 27 deletions

View File

@ -7,7 +7,7 @@
* Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.334 2009/03/11 23:19:24 tgl Exp $
* $PostgreSQL: pgsql/src/backend/access/transam/xlog.c,v 1.335 2009/04/07 00:31:26 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -6914,6 +6914,7 @@ Datum
pg_start_backup(PG_FUNCTION_ARGS)
{
text *backupid = PG_GETARG_TEXT_P(0);
bool fast = PG_GETARG_BOOL(1);
char *backupidstr;
XLogRecPtr checkpointloc;
XLogRecPtr startpoint;
@ -6983,9 +6984,11 @@ pg_start_backup(PG_FUNCTION_ARGS)
* have different checkpoint positions and hence different history
* file names, even if nothing happened in between.
*
* We don't use CHECKPOINT_IMMEDIATE, hence this can take awhile.
* We use CHECKPOINT_IMMEDIATE only if requested by user (via
* passing fast = true). Otherwise this can take awhile.
*/
RequestCheckpoint(CHECKPOINT_FORCE | CHECKPOINT_WAIT);
RequestCheckpoint(CHECKPOINT_FORCE | CHECKPOINT_WAIT |
(fast ? CHECKPOINT_IMMEDIATE : 0));
/*
* Now we need to fetch the checkpoint record location, and also its