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

Remove exclusive backup mode

Browse Source 
Exclusive-mode backups have been deprecated since 9.6 (when
non-exclusive backups were introduced) due to the issues
they can cause should the system crash while one is running and
generally because non-exclusive provides a much better interface.
Further, exclusive backup mode wasn't really being tested (nor was most
of the related code- like being able to log in just to stop an exclusive
backup and the bits of the state machine related to that) and having to
possibly deal with an exclusive backup and the backup_label file
existing during pg_basebackup, pg_rewind, etc, added other complexities
that we are better off without.

This patch removes the exclusive backup mode, the various special cases
for dealing with it, and greatly simplifies the online backup code and
documentation.

Authors: David Steele, Nathan Bossart
Reviewed-by: Chapman Flack
Discussion: https://postgr.es/m/ac7339ca-3718-3c93-929f-99e725d1172c@pgmasters.net
https://postgr.es/m/CAHg+QDfiM+WU61tF6=nPZocMZvHDzCK47Kneyb0ZRULYzV5sKQ@mail.gmail.com
This commit is contained in:
Stephen Frost
2022-04-06 14:41:03 -04:00
parent 14d3f24fa8
commit 39969e2a1e
24 changed files with 246 additions and 1199 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -857,18 +857,9 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
sequence, and that the success of a step is verified before
proceeding to the next step.
</para>
<para>
Low level base backups can be made in a non-exclusive or an exclusive
way. The non-exclusive method is recommended and the exclusive one is
deprecated and will eventually be removed.
</para>
<sect3 id="backup-lowlevel-base-backup-nonexclusive">
<title>Making a Non-Exclusive Low-Level Backup</title>
<para>
A non-exclusive low level backup is one that allows other
concurrent backups to be running (both those started using
the same backup API and those started using
Multiple backups are able to be run concurrently (both those
started using this backup API and those started using
<xref linkend="app-pgbasebackup"/>).
</para>
<para>
@ -881,34 +872,30 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 &amp;&amp; cp pg_wal/0
<listitem>
<para>
Connect to the server (it does not matter which database) as a user with
rights to run pg_start_backup (superuser, or a user who has been granted
rights to run pg_backup_start (superuser, or a user who has been granted
EXECUTE on the function) and issue the command:
<programlisting>
SELECT pg_start_backup('label', false, false);
SELECT pg_backup_start(label => 'label', fast => false);
</programlisting>
where <literal>label</literal> is any string you want to use to uniquely
identify this backup operation. The connection
calling <function>pg_start_backup</function> must be maintained until the end of
calling <function>pg_backup_start</function> must be maintained until the end of
the backup, or the backup will be automatically aborted.
</para>
<para>
By default, <function>pg_start_backup</function> can take a long time to finish.
This is because it performs a checkpoint, and the I/O
required for the checkpoint will be spread out over a significant
period of time, by default half your inter-checkpoint interval
(see the configuration parameter
Online backups are always started at the beginning of a checkpoint.
By default, <function>pg_backup_start</function> will wait for the next
regularly scheduled checkpoint to complete, which may take a long time (see the
configuration parameters <xref linkend="guc-checkpoint-timeout"/> and
<xref linkend="guc-checkpoint-completion-target"/>). This is
usually what you want, because it minimizes the impact on query
processing. If you want to start the backup as soon as
possible, change the second parameter to <literal>true</literal>, which will
issue an immediate checkpoint using as much I/O as available.
usually preferrable as it minimizes the impact on the running system. If you
want to start the backup as soon as possible, pass <literal>true</literal> as
the second parameter to <function>pg_backup_start</function> and it will
request an immediate checkpoint, which will finish as fast as possible using
as much I/O as possible.
</para>
<para>
The third parameter being <literal>false</literal> tells
<function>pg_start_backup</function> to initiate a non-exclusive base backup.
</para>
</listitem>
<listitem>
<para>
@ -926,7 +913,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, true);
SELECT * FROM pg_backup_stop(wait_for_archive => true);
</programlisting>
This terminates backup mode. On a primary, it also performs an automatic
switch to the next WAL segment. On a standby, it is not possible to
@ -937,7 +924,7 @@ SELECT * FROM pg_stop_backup(false, true);
ready to archive.
</para>
<para>
The <function>pg_stop_backup</function> will return one row with three
<function>pg_backup_stop</function> will return one row with three
values. The second of these fields should be written to a file named
<filename>backup_label</filename> in the root directory of the backup. The
third field should be written to a file named
@ -949,14 +936,14 @@ SELECT * FROM pg_stop_backup(false, true);
<listitem>
<para>
Once the WAL segment files active during the backup are archived, you are
done. The file identified by <function>pg_stop_backup</function>'s first return
done. The file identified by <function>pg_backup_stop</function>'s first return
value is the last segment that is required to form a complete set of
backup files. On a primary, if <varname>archive_mode</varname> is enabled and the
<literal>wait_for_archive</literal> parameter is <literal>true</literal>,
<function>pg_stop_backup</function> does not return until the last segment has
<function>pg_backup_stop</function> does not return until the last segment has
been archived.
On a standby, <varname>archive_mode</varname> must be <literal>always</literal> in order
for <function>pg_stop_backup</function> to wait.
for <function>pg_backup_stop</function> to wait.
Archiving of these files happens automatically since you have
already configured <varname>archive_library</varname>. In most cases this
happens quickly, but you are advised to monitor your archive
@ -965,9 +952,9 @@ SELECT * FROM pg_stop_backup(false, true);
because of failures of the archive library, it will keep retrying
until the archive succeeds and the backup is complete.
If you wish to place a time limit on the execution of
<function>pg_stop_backup</function>, set an appropriate
<function>pg_backup_stop</function>, set an appropriate
<varname>statement_timeout</varname> value, but make note that if
<function>pg_stop_backup</function> terminates because of this your backup
<function>pg_backup_stop</function> terminates because of this your backup
may not be valid.
</para>
<para>
@ -975,8 +962,8 @@ SELECT * FROM pg_stop_backup(false, true);
required for the backup are successfully archived then the
<literal>wait_for_archive</literal> parameter (which defaults to true) can be set
to false to have
<function>pg_stop_backup</function> return as soon as the stop backup record is
written to the WAL. By default, <function>pg_stop_backup</function> will wait
<function>pg_backup_stop</function> return as soon as the stop backup record is
written to the WAL. By default, <function>pg_backup_stop</function> 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
@ -985,142 +972,6 @@ SELECT * FROM pg_stop_backup(false, true);
</listitem>
</orderedlist>
</para>
</sect3>
<sect3 id="backup-lowlevel-base-backup-exclusive">
<title>Making an Exclusive Low-Level Backup</title>
<note>
<para>
The exclusive backup method is deprecated and should be avoided.
Prior to <productname>PostgreSQL</productname> 9.6, this was the only
low-level method available, but it is now recommended that all users
upgrade their scripts to use non-exclusive backups.
</para>
</note>
<para>
The process for an exclusive backup is mostly the same as for a
non-exclusive one, but it differs in a few key steps. This type of
backup can only be taken on a primary and does not allow concurrent
backups. Moreover, because it creates a backup label file, as
described below, it can block automatic restart of the primary server
after a crash. On the other hand, the erroneous removal of this
file from a backup or standby is a common mistake, which can result
in serious data corruption. If it is necessary to use this method,
the following steps may be used.
</para>
<para>
<orderedlist>
<listitem>
<para>
Ensure that WAL archiving is enabled and working.
</para>
</listitem>
<listitem>
<para>
Connect to the server (it does not matter which database) as a user with
rights to run pg_start_backup (superuser, or a user who has been granted
EXECUTE on the function) and issue the command:
<programlisting>
SELECT pg_start_backup('label');
</programlisting>
where <literal>label</literal> is any string you want to use to uniquely
identify this backup operation.
<function>pg_start_backup</function> creates a <firstterm>backup label</firstterm> file,
called <filename>backup_label</filename>, in the cluster directory with
information about your backup, including the start time and label string.
The function also creates a <firstterm>tablespace map</firstterm> file,
called <filename>tablespace_map</filename>, in the cluster directory with
information about tablespace symbolic links in <filename>pg_tblspc/</filename> if
one or more such link is present. Both files are critical to the
integrity of the backup, should you need to restore from it.
</para>
<para>
By default, <function>pg_start_backup</function> can take a long time to finish.
This is because it performs a checkpoint, and the I/O
required for the checkpoint will be spread out over a significant
period of time, by default half your inter-checkpoint interval
(see the configuration parameter
<xref linkend="guc-checkpoint-completion-target"/>). This is
usually what you want, because it minimizes the impact on query
processing. If you want to start the backup as soon as
possible, use:
<programlisting>
SELECT pg_start_backup('label', true);
</programlisting>
This forces the checkpoint to be done as quickly as possible.
</para>
</listitem>
<listitem>
<para>
Perform the backup, using any convenient file-system-backup tool
such as <application>tar</application> or <application>cpio</application> (not
<application>pg_dump</application> or
<application>pg_dumpall</application>). It is neither
necessary nor desirable to stop normal operation of the database
while you do this. See
<xref linkend="backup-lowlevel-base-backup-data"/> for things to
consider during this backup.
</para>
<para>
As noted above, if the server crashes during the backup it may not be
possible to restart until the <filename>backup_label</filename> file has
been manually deleted from the <envar>PGDATA</envar> directory. Note
that it is very important to never remove the
<filename>backup_label</filename> file when restoring a backup, because
this will result in corruption. Confusion about when it is appropriate
to remove this file is a common cause of data corruption when using this
method; be very certain that you remove the file only on an existing
primary and never when building a standby or restoring a backup, even if
you are building a standby that will subsequently be promoted to a new
primary.
</para>
</listitem>
<listitem>
<para>
Again connect to the database as a user with rights to run
pg_stop_backup (superuser, or a user who has been granted EXECUTE on
the function), and issue the command:
<programlisting>
SELECT pg_stop_backup();
</programlisting>
This function terminates backup mode and
performs an automatic switch to the next WAL segment. The reason for the
switch is to arrange for the last WAL segment written during the backup
interval to be ready to archive.
</para>
</listitem>
<listitem>
<para>
Once the WAL segment files active during the backup are archived, you are
done. The file identified by <function>pg_stop_backup</function>'s result is
the last segment that is required to form a complete set of backup files.
If <varname>archive_mode</varname> is enabled,
<function>pg_stop_backup</function> does not return until the last segment has
been archived.
Archiving of these files happens automatically since you have
already configured <varname>archive_command</varname>. In most cases this
happens quickly, but you are advised to monitor your archive
system to ensure there are no delays.
If the archive process has fallen behind
because of failures of the archive command, it will keep retrying
until the archive succeeds and the backup is complete.
</para>
<para>
When using exclusive backup mode, it is absolutely imperative to ensure
that <function>pg_stop_backup</function> completes successfully at the
end of the backup. Even if the backup itself fails, for example due to
lack of disk space, failure to call <function>pg_stop_backup</function>
will leave the server in backup mode indefinitely, causing future backups
to fail and increasing the risk of a restart failure during the time that
<filename>backup_label</filename> exists.
</para>
</listitem>
</orderedlist>
</para>
</sect3>
<sect3 id="backup-lowlevel-base-backup-data">
<title>Backing Up the Data Directory</title>
<para>
@ -1203,8 +1054,8 @@ SELECT pg_stop_backup();
<para>
The backup label
file includes the label string you gave to <function>pg_start_backup</function>,
as well as the time at which <function>pg_start_backup</function> was run, and
file includes the label string you gave to <function>pg_backup_start</function>,
as well as the time at which <function>pg_backup_start</function> was run, and
the name of the starting WAL file. In case of confusion it is therefore
possible to look inside a backup file and determine exactly which
backup session the dump file came from. The tablespace map file includes
@ -1218,7 +1069,7 @@ SELECT pg_stop_backup();
<para>
It is also possible to make a backup while the server is
stopped. In this case, you obviously cannot use
<function>pg_start_backup</function> or <function>pg_stop_backup</function>, and
<function>pg_backup_start</function> or <function>pg_backup_stop</function>, and
you will therefore be left to your own devices to keep track of which
backup is which and how far back the associated WAL files go.
It is generally better to follow the continuous archiving procedure above.
@ -1393,7 +1244,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
<note>
<para>
The stop point must be after the ending time of the base backup, i.e.,
the end time of <function>pg_stop_backup</function>. You cannot use a base backup
the end time of <function>pg_backup_stop</function>. You cannot use a base backup
to recover to a time when that backup was in progress. (To
recover to such a time, you must go back to your previous base backup
and roll forward from there.)
@ -1513,44 +1364,6 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
included in the backup automatically, and no special action is
required to restore the backup.
</para>
<para>
If more flexibility in copying the backup files is needed, a lower
level process can be used for standalone hot backups as well.
To prepare for low level standalone hot backups, make sure
<varname>wal_level</varname> is set to
<literal>replica</literal> or higher, <varname>archive_mode</varname> to
<literal>on</literal>, and set up an <varname>archive_library</varname> that performs
archiving only when a <emphasis>switch file</emphasis> exists. For example:
<programlisting>
archive_library = '' # use shell command
archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f &amp;&amp; cp %p /var/lib/pgsql/archive/%f)'
</programlisting>
This command will perform archiving when
<filename>/var/lib/pgsql/backup_in_progress</filename> exists, and otherwise
silently return zero exit status (allowing <productname>PostgreSQL</productname>
to recycle the unwanted WAL file).
</para>
<para>
With this preparation, a backup can be taken using a script like the
following:
<programlisting>
touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
</programlisting>
The switch file <filename>/var/lib/pgsql/backup_in_progress</filename> is
created first, enabling archiving of completed WAL files to occur.
After the backup the switch file is removed. Archived WAL files are
then added to the backup so that both base backup and all required
WAL files are part of the same <application>tar</application> file.
Please remember to add error handling to your backup scripts.
</para>
</sect3>
<sect3 id="compressed-archive-logs">

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

@ -25618,9 +25618,8 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
The functions shown in <xref
linkend="functions-admin-backup-table"/> assist in making on-line backups.
These functions cannot be executed during recovery (except
non-exclusive <function>pg_start_backup</function>,
non-exclusive <function>pg_stop_backup</function>,
<function>pg_is_in_backup</function>, <function>pg_backup_start_time</function>
<function>pg_backup_start</function>,
<function>pg_backup_stop</function>,
and <function>pg_wal_lsn_diff</function>).
</para>
@ -25709,13 +25708,12 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_start_backup</primary>
<primary>pg_backup_start</primary>
</indexterm>
<function>pg_start_backup</function> (
<function>pg_backup_start</function> (
<parameter>label</parameter> <type>text</type>
<optional>, <parameter>fast</parameter> <type>boolean</type>
<optional>, <parameter>exclusive</parameter> <type>boolean</type>
</optional></optional> )
</optional> )
<returnvalue>pg_lsn</returnvalue>
</para>
<para>
@ -25724,23 +25722,9 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
(Typically this would be the name under which the backup dump file
will be stored.)
If the optional second parameter is given as <literal>true</literal>,
it specifies executing <function>pg_start_backup</function> as quickly
it specifies executing <function>pg_backup_start</function> as quickly
as possible. This forces an immediate checkpoint which will cause a
spike in I/O operations, slowing any concurrently executing queries.
The optional third parameter specifies whether to perform an exclusive
or non-exclusive backup (default is exclusive).
</para>
<para>
When used in exclusive mode, this function writes a backup label file
(<filename>backup_label</filename>) and, if there are any links in
the <filename>pg_tblspc/</filename> directory, a tablespace map file
(<filename>tablespace_map</filename>) into the database cluster's data
directory, then performs a checkpoint, and then returns the backup's
starting write-ahead log location. (The user can ignore this
result value, but it is provided in case it is useful.) When used in
non-exclusive mode, the contents of these files are instead returned
by the <function>pg_stop_backup</function> function, and should be
copied to the backup area by the user.
</para>
<para>
This function is restricted to superusers by default, but other users
@ -25751,11 +25735,10 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stop_backup</primary>
<primary>pg_backup_stop</primary>
</indexterm>
<function>pg_stop_backup</function> (
<parameter>exclusive</parameter> <type>boolean</type>
<optional>, <parameter>wait_for_archive</parameter> <type>boolean</type>
<function>pg_backup_stop</function> (
<optional><parameter>wait_for_archive</parameter> <type>boolean</type>
</optional> )
<returnvalue>record</returnvalue>
( <parameter>lsn</parameter> <type>pg_lsn</type>,
@ -25763,24 +25746,21 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
<parameter>spcmapfile</parameter> <type>text</type> )
</para>
<para>
Finishes performing an exclusive or non-exclusive on-line backup.
The <parameter>exclusive</parameter> parameter must match the
previous <function>pg_start_backup</function> call.
In an exclusive backup, <function>pg_stop_backup</function> removes
the backup label file and, if it exists, the tablespace map file
created by <function>pg_start_backup</function>. In a non-exclusive
backup, the desired contents of these files are returned as part of
the result of the function, and should be written to files in the
backup area (not in the data directory).
Finishes performing an on-line backup. The desired contents of the
backup label file and the tablespace map file are returned as part of
the result of the function and must be written to files in the
backup area. These files must not be written to the live data directory
(doing so will cause PostgreSQL to fail to restart in the event of a
crash).
</para>
<para>
There is an optional second parameter of type <type>boolean</type>.
There is an optional parameter of type <type>boolean</type>.
If false, the function will return immediately after the backup is
completed, without waiting for WAL to be archived. This behavior is
only useful with backup software that independently monitors WAL
archiving. Otherwise, WAL required to make the backup consistent might
be missing and make the backup useless. By default or when this
parameter is true, <function>pg_stop_backup</function> will wait for
parameter is true, <function>pg_backup_stop</function> will wait for
WAL to be archived when archiving is enabled. (On a standby, this
means that it will wait only when <varname>archive_mode</varname> =
<literal>always</literal>. If write activity on the primary is low,
@ -25790,7 +25770,7 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
<para>
When executed on a primary, this function also creates a backup
history file in the write-ahead log archive area. The history file
includes the label given to <function>pg_start_backup</function>, the
includes the label given to <function>pg_backup_start</function>, the
starting and ending write-ahead log locations for the backup, and the
starting and ending times of the backup. After recording the ending
location, the current write-ahead log insertion point is automatically
@ -25801,10 +25781,11 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
<para>
The result of the function is a single record.
The <parameter>lsn</parameter> column holds the backup's ending
write-ahead log location (which again can be ignored). The second and
third columns are <literal>NULL</literal> when ending an exclusive
backup; after a non-exclusive backup they hold the desired contents of
the label and tablespace map files.
write-ahead log location (which again can be ignored). The second
column returns the contents of the backup label file, and the third
column returns the contents of the tablespace map file. These must be
stored as part of the backup and are required as part of the restore
process.
</para>
<para>
This function is restricted to superusers by default, but other users
@ -25812,50 +25793,6 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<function>pg_stop_backup</function> ()
<returnvalue>pg_lsn</returnvalue>
</para>
<para>
Finishes performing an exclusive on-line backup. This simplified
version is equivalent to <literal>pg_stop_backup(true,
true)</literal>, except that it only returns the <type>pg_lsn</type>
result.
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_is_in_backup</primary>
</indexterm>
<function>pg_is_in_backup</function> ()
<returnvalue>boolean</returnvalue>
</para>
<para>
Returns true if an on-line exclusive backup is in progress.
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_backup_start_time</primary>
</indexterm>
<function>pg_backup_start_time</function> ()
<returnvalue>timestamp with time zone</returnvalue>
</para>
<para>
Returns the start time of the current on-line exclusive backup if one
is in progress, otherwise <literal>NULL</literal>.
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
@ -25953,7 +25890,7 @@ LOG: Grand total: 1651920 bytes in 201 blocks; 622360 free (88 chunks); 1029560
corresponding write-ahead log file name and byte offset from
a <type>pg_lsn</type> value. For example:
<programlisting>
postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
postgres=# SELECT * FROM pg_walfile_name_offset((pg_backup_stop()).lsn);
file_name | file_offset
--------------------------+-------------
00000001000000000000000D | 4039624

6
doc/src/sgml/high-availability.sgml
View File

@ -1361,8 +1361,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
<para>
If you need to re-create a standby server while transactions are
waiting, make sure that the commands pg_start_backup() and
pg_stop_backup() are run in a session with
waiting, make sure that the commands pg_backup_start() and
pg_backup_stop() are run in a session with
<varname>synchronous_commit</varname> = <literal>off</literal>, otherwise those
requests will wait forever for the standby to appear.
</para>
@ -2159,7 +2159,7 @@ HINT: You can then restart the server after making the necessary configuration
<para>
WAL file control commands will not work during recovery,
e.g., <function>pg_start_backup</function>, <function>pg_switch_wal</function> etc.
e.g., <function>pg_backup_start</function>, <function>pg_switch_wal</function> etc.
</para>
<para>

4
doc/src/sgml/monitoring.sgml
View File

@ -6674,7 +6674,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<entry><literal>waiting for checkpoint to finish</literal></entry>
<entry>
The WAL sender process is currently performing
<function>pg_start_backup</function> to prepare to
<function>pg_backup_start</function> to prepare to
take a base backup, and waiting for the start-of-backup
checkpoint to finish.
</entry>
@ -6697,7 +6697,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<entry><literal>waiting for wal archiving to finish</literal></entry>
<entry>
The WAL sender process is currently performing
<function>pg_stop_backup</function> to finish the backup,
<function>pg_backup_stop</function> to finish the backup,
and waiting for all the WAL files required for the base backup
to be successfully archived.
If either <literal>--wal-method=none</literal> or

6
doc/src/sgml/ref/pg_ctl-ref.sgml
View File

@ -186,11 +186,11 @@ PostgreSQL documentation
the specified data directory. Three different
shutdown methods can be selected with the <option>-m</option>
option. <quote>Smart</quote> mode disallows new connections, then waits
for all existing clients to disconnect and any online backup to finish.
for all existing clients to disconnect.
If the server is in hot standby, recovery and streaming replication
will be terminated once all clients have disconnected.
<quote>Fast</quote> mode (the default) does not wait for clients to disconnect and
will terminate an online backup in progress. All active transactions are
<quote>Fast</quote> mode (the default) does not wait for clients to disconnect.
All active transactions are
rolled back and clients are forcibly disconnected, then the
server is shut down. <quote>Immediate</quote> mode will abort
all server processes immediately, without a clean shutdown. This choice

2
doc/src/sgml/ref/pgupgrade.sgml
View File

@ -618,7 +618,7 @@ rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tb
<para>
Configure the servers for log shipping. (You do not need to run
<function>pg_start_backup()</function> and <function>pg_stop_backup()</function>
<function>pg_backup_start()</function> and <function>pg_backup_stop()</function>
or take a file system backup as the standbys are still synchronized
with the primary.)
</para>

8
doc/src/sgml/runtime.sgml
View File

@ -1552,11 +1552,7 @@ $ <userinput>cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages</userinp
After receiving <systemitem>SIGTERM</systemitem>, the server
disallows new connections, but lets existing sessions end their
work normally. It shuts down only after all of the sessions terminate.
If the server is in online backup mode, it additionally waits
until online backup mode is no longer active. While backup mode is
active, new connections will still be allowed, but only to superusers
(this exception allows a superuser to connect to terminate
online backup mode). If the server is in recovery when a smart
If the server is in recovery when a smart
shutdown is requested, recovery and streaming replication will be
stopped only after all regular sessions have terminated.
</para>
@ -1572,8 +1568,6 @@ $ <userinput>cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages</userinp
server processes <systemitem>SIGTERM</systemitem>, which will cause them
to abort their current transactions and exit promptly. It then
waits for all server processes to exit and finally shuts down.
If the server is in online backup mode, backup mode will be
terminated, rendering the backup useless.
</para>
</listitem>
</varlistentry>