|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.97 2007/02/01 00:28:16 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.98 2007/06/29 15:46:21 tgl Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="backup"> |
4 | 4 | <title>Backup and Restore</title> |
@@ -674,6 +674,22 @@ SELECT pg_start_backup('label'); |
674 | 674 | issue this command. You can ignore the result returned by the function; |
675 | 675 | but if it reports an error, deal with that before proceeding. |
676 | 676 | </para> |
| 677 | + |
| 678 | + <para> |
| 679 | + <function>pg_start_backup</> can take a long time to finish. |
| 680 | + This is because it performs a checkpoint, and the I/O |
| 681 | + required for a checkpoint will be spread out over a significant |
| 682 | + period of time, by default half your inter-checkpoint interval |
| 683 | + (see the configuration parameter |
| 684 | + <xref linkend="guc-checkpoint-completion-target">). Usually |
| 685 | + this is what you want because it minimizes the impact on query |
| 686 | + processing. If you just want to start the backup as soon as |
| 687 | + possible, execute a <command>CHECKPOINT</> command |
| 688 | + (which performs a checkpoint as quickly as possible) and then |
| 689 | + immediately execute <function>pg_start_backup</>. Then there |
| 690 | + will be very little for <function>pg_start_backup</>'s checkpoint |
| 691 | + to do, and it won't take long. |
| 692 | + </para> |
677 | 693 | </listitem> |
678 | 694 | <listitem> |
679 | 695 | <para> |
|