database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Expose waitforarchive option through pg_stop_backup()

Browse Source 
Internally, we have supported the option to either wait for all of the
WAL associated with a backup to be archived, or to return immediately.
This option is useful to users of pg_stop_backup() as well, when they
are reading the stop backup record position and checking that the WAL
they need has been archived independently.

This patch adds an additional, optional, argument to pg_stop_backup()
which allows the user to indicate if they wish to wait for the WAL to be
archived or not.  The default matches current behavior, which is to
wait.

Author: David Steele, with some minor changes, doc updates by me.
Reviewed by: Takayuki Tsunakawa, Fujii Masao
Discussion: https://postgr.es/m/758e3fd1-45b4-5e28-75cd-e9e7f93a4c02@pgmasters.net
This commit is contained in:
Stephen Frost
2017-03-22 23:44:58 -04:00
parent cbf7ed51b8
commit 017e4f2588
7 changed files with 41 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/src/sgml/backup.sgml
View File

@ -887,7 +887,7 @@ SELECT pg_start_backup('label', false, false);
<para>
In the same connection as before, issue the command:
<programlisting>
SELECT * FROM pg_stop_backup(false);
SELECT * FROM pg_stop_backup(false, true);
</programlisting>
This terminates the backup mode and performs an automatic switch to
the next WAL segment. The reason for the switch is to arrange for
@ -924,6 +924,17 @@ SELECT * FROM pg_stop_backup(false);
<function>pg_stop_backup</> terminates because of this your backup
may not be valid.
</para>
<para>
If the backup process monitors and ensures that all WAL segment files
required for the backup are successfully archived then the second
parameter (which defaults to true) can be set to false to have
<function>pg_stop_backup</> return as soon as the stop backup record is
written to the WAL. By default, <function>pg_stop_backup</> will wait
until all WAL has been archived, which can take some time. This option
must be used with caution: if WAL archiving is not monitored correctly
then the backup might not include all of the WAL files and will
therefore be incomplete and not able to be restored.
</para>
</listitem>
</orderedlist>
</para>

10
doc/src/sgml/func.sgml
View File

@ -18355,7 +18355,7 @@ SELECT set_config('log_statement_stats', 'off', false);
</row>
<row>
<entry>
<literal><function>pg_stop_backup(<parameter>exclusive</> <type>boolean</>)</function></literal>
<literal><function>pg_stop_backup(<parameter>exclusive</> <type>boolean</> <optional>, <parameter>wait_for_archive</> <type>boolean</> </optional>)</function></literal>
</entry>
<entry><type>setof record</type></entry>
<entry>Finish performing exclusive or non-exclusive on-line backup (restricted to superusers by default, but other users can be granted EXECUTE to run the function)</entry>
@ -18439,7 +18439,13 @@ postgres=# select pg_start_backup('label_goes_here');
<function>pg_start_backup</>. In a non-exclusive backup, the contents of
the <filename>backup_label</> and <filename>tablespace_map</> are returned
in the result of the function, and should be written to files in the
backup (and not in the data directory).
backup (and not in the data directory). There is an optional second
parameter of type boolean. If false, the <function>pg_stop_backup</>
will return immediately after the backup is completed without waiting for
WAL to be archived. This behavior is only useful for backup
software which independently monitors WAL archiving. Otherwise, WAL
required to make the backup consistent might be missing and make the backup
useless.
</para>
<para>