mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
Expose waitforarchive option through pg_stop_backup()
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:
@ -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>
|
||||
|
@ -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>
|
||||
|
Reference in New Issue
Block a user