2011-10-26 20:13:33 +02:00
|
|
|
<!--
|
2017-02-09 22:23:46 +01:00
|
|
|
doc/src/sgml/ref/pg_receivewal.sgml
|
2011-10-26 20:13:33 +02:00
|
|
|
PostgreSQL documentation
|
|
|
|
-->
|
|
|
|
|
2017-02-09 22:23:46 +01:00
|
|
|
<refentry id="app-pgreceivewal">
|
|
|
|
<indexterm zone="app-pgreceivewal">
|
|
|
|
<primary>pg_receivewal</primary>
|
2014-02-24 03:25:35 +01:00
|
|
|
</indexterm>
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
<refmeta>
|
2020-07-10 16:51:29 +02:00
|
|
|
<refentrytitle><application>pg_receivewal</application></refentrytitle>
|
2011-10-26 20:13:33 +02:00
|
|
|
<manvolnum>1</manvolnum>
|
|
|
|
<refmiscinfo>Application</refmiscinfo>
|
|
|
|
</refmeta>
|
|
|
|
|
|
|
|
<refnamediv>
|
2017-02-09 22:23:46 +01:00
|
|
|
<refname>pg_receivewal</refname>
|
2017-05-12 17:49:56 +02:00
|
|
|
<refpurpose>stream write-ahead logs from a <productname>PostgreSQL</productname> server</refpurpose>
|
2011-10-26 20:13:33 +02:00
|
|
|
</refnamediv>
|
|
|
|
|
|
|
|
<refsynopsisdiv>
|
|
|
|
<cmdsynopsis>
|
2017-02-09 22:23:46 +01:00
|
|
|
<command>pg_receivewal</command>
|
2017-10-09 03:44:17 +02:00
|
|
|
<arg rep="repeat"><replaceable>option</replaceable></arg>
|
2011-10-26 20:13:33 +02:00
|
|
|
</cmdsynopsis>
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
<refsect1>
|
2020-06-07 13:10:18 +02:00
|
|
|
<title>Description</title>
|
2011-10-26 20:13:33 +02:00
|
|
|
<para>
|
2017-05-12 17:49:56 +02:00
|
|
|
<application>pg_receivewal</application> is used to stream the write-ahead log
|
|
|
|
from a running <productname>PostgreSQL</productname> cluster. The write-ahead
|
2011-10-26 20:13:33 +02:00
|
|
|
log is streamed using the streaming replication protocol, and is written
|
|
|
|
to a local directory of files. This directory can be used as the archive
|
|
|
|
location for doing a restore using point-in-time recovery (see
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="continuous-archiving"/>).
|
2011-10-26 20:13:33 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-05-12 17:49:56 +02:00
|
|
|
<application>pg_receivewal</application> streams the write-ahead
|
2011-10-26 20:13:33 +02:00
|
|
|
log in real time as it's being generated on the server, and does not wait
|
2022-09-17 11:34:20 +02:00
|
|
|
for segments to complete like <xref linkend="guc-archive-command"/> and
|
|
|
|
<xref linkend="guc-archive-library"/> do.
|
2011-10-26 20:13:33 +02:00
|
|
|
For this reason, it is not necessary to set
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="guc-archive-timeout"/> when using
|
2017-02-09 22:23:46 +01:00
|
|
|
<application>pg_receivewal</application>.
|
2011-10-26 20:13:33 +02:00
|
|
|
</para>
|
|
|
|
|
2014-11-17 18:32:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Unlike the WAL receiver of a PostgreSQL standby server, <application>pg_receivewal</application>
|
2015-09-18 02:56:58 +02:00
|
|
|
by default flushes WAL data only when a WAL file is closed.
|
2017-10-09 03:44:17 +02:00
|
|
|
The option <option>--synchronous</option> must be specified to flush WAL data
|
2019-07-24 04:25:43 +02:00
|
|
|
in real time. Since <application>pg_receivewal</application> does not
|
|
|
|
apply WAL, you should not allow it to become a synchronous standby when
|
|
|
|
<xref linkend="guc-synchronous-commit"/> equals
|
|
|
|
<literal>remote_apply</literal>. If it does, it will appear to be a
|
|
|
|
standby that never catches up, and will cause transaction commits to
|
|
|
|
block. To avoid this, you should either configure an appropriate value
|
|
|
|
for <xref linkend="guc-synchronous-standby-names"/>, or specify
|
|
|
|
<varname>application_name</varname> for
|
|
|
|
<application>pg_receivewal</application> that does not match it, or
|
|
|
|
change the value of <varname>synchronous_commit</varname> to
|
|
|
|
something other than <literal>remote_apply</literal>.
|
2014-11-17 18:32:48 +01:00
|
|
|
</para>
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
<para>
|
2017-05-12 17:49:56 +02:00
|
|
|
The write-ahead log is streamed over a regular
|
2015-11-19 20:19:04 +01:00
|
|
|
<productname>PostgreSQL</productname> connection and uses the replication
|
2020-06-07 13:24:40 +02:00
|
|
|
protocol. The connection must be made with a user having
|
2020-05-05 07:16:01 +02:00
|
|
|
<literal>REPLICATION</literal> permissions (see
|
|
|
|
<xref linkend="role-attributes"/>) or a superuser, and
|
|
|
|
<filename>pg_hba.conf</filename> must permit the replication connection.
|
|
|
|
The server must also be configured with
|
|
|
|
<xref linkend="guc-max-wal-senders"/> set high enough to leave at least
|
|
|
|
one session available for the stream.
|
2011-10-26 20:13:33 +02:00
|
|
|
</para>
|
2012-05-27 11:05:24 +02:00
|
|
|
|
2021-10-23 07:43:03 +02:00
|
|
|
<para>
|
|
|
|
The starting point of the write-ahead log streaming is calculated when
|
|
|
|
<application>pg_receivewal</application> starts:
|
|
|
|
<orderedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
First, scan the directory where the WAL segment files are written and
|
2022-01-25 01:40:04 +01:00
|
|
|
find the newest completed segment file, using as the starting point the
|
|
|
|
beginning of the next WAL segment file.
|
2021-10-23 07:43:03 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
Allow pg_receivewal to stream from a slot's restart LSN
Prior to this patch, when running pg_receivewal, the streaming start
point would be the current location of the archives if anything is
found in the local directory where WAL segments are written, and
pg_receivewal would fall back to the current WAL flush location if there
are no archives, as of the result of an IDENTIFY_SYSTEM command.
If for some reason the WAL files from pg_receivewal were moved, it is
better to try a restart where we left at, which is the replication
slot's restart_lsn instead of skipping right to the current flush
location, to avoid holes in the WAL backed up. This commit changes
pg_receivewal to use the following sequence of methods to determine the
starting streaming LSN:
- Scan the local archives.
- Use the slot's restart_lsn, if supported by the backend and if a slot
is defined.
- Fallback to the current flush LSN as reported by IDENTIFY_SYSTEM.
To keep compatibility with older server versions, we only attempt to use
READ_REPLICATION_SLOT if the backend version is at least 15, and
fallback to the older behavior of streaming from the current flush
LSN if the command is not supported.
Some TAP tests are added to cover this feature.
Author: Ronan Dunklau
Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Bharath Rupireddy
Discussion: https://postgr.es/m/18708360.4lzOvYHigE@aivenronan
2021-10-26 02:30:37 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2021-10-26 06:57:18 +02:00
|
|
|
If a starting point cannot be calculated with the previous method,
|
Allow pg_receivewal to stream from a slot's restart LSN
Prior to this patch, when running pg_receivewal, the streaming start
point would be the current location of the archives if anything is
found in the local directory where WAL segments are written, and
pg_receivewal would fall back to the current WAL flush location if there
are no archives, as of the result of an IDENTIFY_SYSTEM command.
If for some reason the WAL files from pg_receivewal were moved, it is
better to try a restart where we left at, which is the replication
slot's restart_lsn instead of skipping right to the current flush
location, to avoid holes in the WAL backed up. This commit changes
pg_receivewal to use the following sequence of methods to determine the
starting streaming LSN:
- Scan the local archives.
- Use the slot's restart_lsn, if supported by the backend and if a slot
is defined.
- Fallback to the current flush LSN as reported by IDENTIFY_SYSTEM.
To keep compatibility with older server versions, we only attempt to use
READ_REPLICATION_SLOT if the backend version is at least 15, and
fallback to the older behavior of streaming from the current flush
LSN if the command is not supported.
Some TAP tests are added to cover this feature.
Author: Ronan Dunklau
Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Bharath Rupireddy
Discussion: https://postgr.es/m/18708360.4lzOvYHigE@aivenronan
2021-10-26 02:30:37 +02:00
|
|
|
and if a replication slot is used, an extra
|
|
|
|
<command>READ_REPLICATION_SLOT</command> command is issued to retrieve
|
2022-01-25 01:40:04 +01:00
|
|
|
the slot's <literal>restart_lsn</literal> to use as the starting point.
|
Allow pg_receivewal to stream from a slot's restart LSN
Prior to this patch, when running pg_receivewal, the streaming start
point would be the current location of the archives if anything is
found in the local directory where WAL segments are written, and
pg_receivewal would fall back to the current WAL flush location if there
are no archives, as of the result of an IDENTIFY_SYSTEM command.
If for some reason the WAL files from pg_receivewal were moved, it is
better to try a restart where we left at, which is the replication
slot's restart_lsn instead of skipping right to the current flush
location, to avoid holes in the WAL backed up. This commit changes
pg_receivewal to use the following sequence of methods to determine the
starting streaming LSN:
- Scan the local archives.
- Use the slot's restart_lsn, if supported by the backend and if a slot
is defined.
- Fallback to the current flush LSN as reported by IDENTIFY_SYSTEM.
To keep compatibility with older server versions, we only attempt to use
READ_REPLICATION_SLOT if the backend version is at least 15, and
fallback to the older behavior of streaming from the current flush
LSN if the command is not supported.
Some TAP tests are added to cover this feature.
Author: Ronan Dunklau
Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Bharath Rupireddy
Discussion: https://postgr.es/m/18708360.4lzOvYHigE@aivenronan
2021-10-26 02:30:37 +02:00
|
|
|
This option is only available when streaming write-ahead logs from
|
|
|
|
<productname>PostgreSQL</productname> 15 and up.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
|
2021-10-23 07:43:03 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
If a starting point cannot be calculated with the previous method,
|
|
|
|
the latest WAL flush location is used as reported by the server from
|
2022-01-25 01:40:04 +01:00
|
|
|
an <literal>IDENTIFY_SYSTEM</literal> command.
|
2021-10-23 07:43:03 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
|
|
</para>
|
|
|
|
|
2012-05-27 11:05:24 +02:00
|
|
|
<para>
|
|
|
|
If the connection is lost, or if it cannot be initially established,
|
2017-02-09 22:23:46 +01:00
|
|
|
with a non-fatal error, <application>pg_receivewal</application> will
|
2012-05-27 11:05:24 +02:00
|
|
|
retry the connection indefinitely, and reestablish streaming as soon
|
|
|
|
as possible. To avoid this behavior, use the <literal>-n</literal>
|
|
|
|
parameter.
|
|
|
|
</para>
|
2017-08-16 02:26:58 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
In the absence of fatal errors, <application>pg_receivewal</application>
|
2022-09-14 16:32:24 +02:00
|
|
|
will run until terminated by the <systemitem>SIGINT</systemitem>
|
|
|
|
(<keycombo action="simul"><keycap>Control</keycap><keycap>C</keycap></keycombo>)
|
|
|
|
or <systemitem>SIGTERM</systemitem> signal.
|
2017-08-16 02:26:58 +02:00
|
|
|
</para>
|
2011-10-26 20:13:33 +02:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Options</title>
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term><option>-D <replaceable class="parameter">directory</replaceable></option></term>
|
2012-06-11 23:55:27 +02:00
|
|
|
<term><option>--directory=<replaceable class="parameter">directory</replaceable></option></term>
|
2011-10-26 20:13:33 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Directory to write the output to.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
This parameter is required.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2012-05-27 11:05:24 +02:00
|
|
|
|
2017-09-11 22:30:50 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>-E <replaceable>lsn</replaceable></option></term>
|
|
|
|
<term><option>--endpos=<replaceable>lsn</replaceable></option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Automatically stop replication and exit with normal exit status 0 when
|
|
|
|
receiving reaches the specified LSN.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
If there is a record with LSN exactly equal to <replaceable>lsn</replaceable>,
|
2017-09-11 22:30:50 +02:00
|
|
|
the record will be processed.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2015-07-12 22:06:27 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>--if-not-exists</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2016-07-20 10:39:18 +02:00
|
|
|
Do not error out when <option>--create-slot</option> is specified
|
2015-07-12 22:06:27 +02:00
|
|
|
and a slot with the specified name already exists.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2014-10-18 15:10:12 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>-n</option></term>
|
|
|
|
<term><option>--no-loop</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Don't loop on connection errors. Instead, exit right away with
|
|
|
|
an error.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2017-10-29 08:16:55 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>--no-sync</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
This option causes <command>pg_receivewal</command> to not force WAL
|
|
|
|
data to be flushed to disk. This is faster, but means that a
|
|
|
|
subsequent operating system crash can leave the WAL segments corrupt.
|
|
|
|
Generally, this option is useful for testing but should not be used
|
|
|
|
when doing WAL archiving on a production deployment.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This option is incompatible with <literal>--synchronous</literal>.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2014-10-18 15:10:12 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>-s <replaceable class="parameter">interval</replaceable></option></term>
|
|
|
|
<term><option>--status-interval=<replaceable class="parameter">interval</replaceable></option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies the number of seconds between status packets sent back to the
|
|
|
|
server. This allows for easier monitoring of the progress from server.
|
|
|
|
A value of zero disables the periodic status updates completely,
|
|
|
|
although an update will still be sent when requested by the server, to
|
|
|
|
avoid timeout disconnect. The default value is 10 seconds.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><option>-S <replaceable>slotname</replaceable></option></term>
|
|
|
|
<term><option>--slot=<replaceable class="parameter">slotname</replaceable></option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-02-09 22:23:46 +01:00
|
|
|
Require <application>pg_receivewal</application> to use an existing
|
2017-11-23 15:39:47 +01:00
|
|
|
replication slot (see <xref linkend="streaming-replication-slots"/>).
|
2017-10-09 03:44:17 +02:00
|
|
|
When this option is used, <application>pg_receivewal</application> will report
|
2014-10-18 15:10:12 +02:00
|
|
|
a flush position to the server, indicating when each segment has been
|
|
|
|
synchronized to disk so that the server can remove that segment if it
|
2015-11-19 20:19:04 +01:00
|
|
|
is not otherwise needed.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
When the replication client
|
2017-02-09 22:23:46 +01:00
|
|
|
of <application>pg_receivewal</application> is configured on the
|
2015-11-19 20:19:04 +01:00
|
|
|
server as a synchronous standby, then using a replication slot will
|
|
|
|
report the flush position to the server, but only when a WAL file is
|
|
|
|
closed. Therefore, that configuration will cause transactions on the
|
|
|
|
primary to wait for a long time and effectively not work
|
|
|
|
satisfactorily. The option <literal>--synchronous</literal> (see
|
|
|
|
below) must be specified in addition to make this work correctly.
|
2014-10-18 15:10:12 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2014-11-17 18:32:48 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>--synchronous</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2015-02-03 09:35:46 +01:00
|
|
|
Flush the WAL data to disk immediately after it has been received. Also
|
|
|
|
send a status packet back to the server immediately after flushing,
|
2017-10-09 03:44:17 +02:00
|
|
|
regardless of <literal>--status-interval</literal>.
|
2014-11-17 18:32:48 +01:00
|
|
|
</para>
|
2015-11-19 20:19:04 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
This option should be specified if the replication client
|
2017-02-09 22:23:46 +01:00
|
|
|
of <application>pg_receivewal</application> is configured on the
|
2015-11-19 20:19:04 +01:00
|
|
|
server as a synchronous standby, to ensure that timely feedback is
|
|
|
|
sent to the server.
|
|
|
|
</para>
|
2014-11-17 18:32:48 +01:00
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>-v</option></term>
|
|
|
|
<term><option>--verbose</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Enables verbose mode.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2017-01-17 12:10:26 +01:00
|
|
|
|
Rework compression options of pg_receivewal
pg_receivewal includes since cada1af the option --compress, to allow the
compression of WAL segments using gzip, with a value of 0 (the default)
meaning that no compression can be used.
This commit introduces a new option, called --compression-method, able
to use as values "none", the default, and "gzip", to make things more
extensible. The case of --compress=0 becomes fuzzy with this option
layer, so we have made the choice to make pg_receivewal return an error
when using "none" and a non-zero compression level, meaning that the
authorized values of --compress are now [1,9] instead of [0,9]. Not
specifying --compress with "gzip" as compression method makes
pg_receivewal use the default of zlib instead (Z_DEFAULT_COMPRESSION).
The code in charge of finding the streaming start LSN when scanning the
existing archives is refactored and made more extensible. While on it,
rename "compression" to "compression_level" in walmethods.c, to reduce
the confusion with the introduction of the compression method, even if
the tar method used by pg_basebackup does not rely on the compression
method (yet, at least), but just on the compression level (this area
could be improved more, actually).
This is in preparation for an upcoming patch that adds LZ4 support to
pg_receivewal.
Author: Georgios Kokolatos
Reviewed-by: Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar,
Robert Haas
Discussion: https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me
2021-11-04 03:10:31 +01:00
|
|
|
<varlistentry>
|
Rework compression options of pg_receivewal
Since babbbb5 and the introduction of LZ4 in pg_receivewal, the
compression of the WAL archived is controlled by two options:
- --compression-method with "gzip", "none" or "lz4" as possible value.
- --compress=N to specify a compression level. This includes a
backward-incompatible change where a value of 0 leads to a failure
instead of no compression enforced.
This commit takes advantage of a4b5754 and 3603f7c to rework the
compression options of pg_receivewal, as of:
- The removal of --compression-method.
- The extenction of --compress to use the same grammar as pg_basebackup,
with a METHOD:DETAIL format, where a METHOD is "gzip", "none" or "lz4"
and a DETAIL is a comma-separated list of options, the only keyword
supported is now "level" to control the compression level. If only an
integer is specified as value of this option, "none" is implied on 0
and "gzip" is implied otherwise. This brings back --compress to be
backward-compatible with ~14, while still supporting LZ4.
This has also the advantage of centralizing the set of checks used by
pg_receivewal to validate its compression options.
Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/YlPQGNAAa04raObK@paquier.xyz
2022-04-13 04:09:51 +02:00
|
|
|
<term><option>-Z <replaceable class="parameter">level</replaceable></option></term>
|
|
|
|
<term><option>-Z <replaceable class="parameter">method</replaceable>[:<replaceable>detail</replaceable>]</option></term>
|
|
|
|
<term><option>--compress=<replaceable class="parameter">level</replaceable></option></term>
|
|
|
|
<term><option>--compress=<replaceable class="parameter">method</replaceable>[:<replaceable>detail</replaceable>]</option></term>
|
Rework compression options of pg_receivewal
pg_receivewal includes since cada1af the option --compress, to allow the
compression of WAL segments using gzip, with a value of 0 (the default)
meaning that no compression can be used.
This commit introduces a new option, called --compression-method, able
to use as values "none", the default, and "gzip", to make things more
extensible. The case of --compress=0 becomes fuzzy with this option
layer, so we have made the choice to make pg_receivewal return an error
when using "none" and a non-zero compression level, meaning that the
authorized values of --compress are now [1,9] instead of [0,9]. Not
specifying --compress with "gzip" as compression method makes
pg_receivewal use the default of zlib instead (Z_DEFAULT_COMPRESSION).
The code in charge of finding the streaming start LSN when scanning the
existing archives is refactored and made more extensible. While on it,
rename "compression" to "compression_level" in walmethods.c, to reduce
the confusion with the introduction of the compression method, even if
the tar method used by pg_basebackup does not rely on the compression
method (yet, at least), but just on the compression level (this area
could be improved more, actually).
This is in preparation for an upcoming patch that adds LZ4 support to
pg_receivewal.
Author: Georgios Kokolatos
Reviewed-by: Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar,
Robert Haas
Discussion: https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me
2021-11-04 03:10:31 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
Rework compression options of pg_receivewal
Since babbbb5 and the introduction of LZ4 in pg_receivewal, the
compression of the WAL archived is controlled by two options:
- --compression-method with "gzip", "none" or "lz4" as possible value.
- --compress=N to specify a compression level. This includes a
backward-incompatible change where a value of 0 leads to a failure
instead of no compression enforced.
This commit takes advantage of a4b5754 and 3603f7c to rework the
compression options of pg_receivewal, as of:
- The removal of --compression-method.
- The extenction of --compress to use the same grammar as pg_basebackup,
with a METHOD:DETAIL format, where a METHOD is "gzip", "none" or "lz4"
and a DETAIL is a comma-separated list of options, the only keyword
supported is now "level" to control the compression level. If only an
integer is specified as value of this option, "none" is implied on 0
and "gzip" is implied otherwise. This brings back --compress to be
backward-compatible with ~14, while still supporting LZ4.
This has also the advantage of centralizing the set of checks used by
pg_receivewal to validate its compression options.
Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/YlPQGNAAa04raObK@paquier.xyz
2022-04-13 04:09:51 +02:00
|
|
|
Enables compression of write-ahead logs.
|
Rework compression options of pg_receivewal
pg_receivewal includes since cada1af the option --compress, to allow the
compression of WAL segments using gzip, with a value of 0 (the default)
meaning that no compression can be used.
This commit introduces a new option, called --compression-method, able
to use as values "none", the default, and "gzip", to make things more
extensible. The case of --compress=0 becomes fuzzy with this option
layer, so we have made the choice to make pg_receivewal return an error
when using "none" and a non-zero compression level, meaning that the
authorized values of --compress are now [1,9] instead of [0,9]. Not
specifying --compress with "gzip" as compression method makes
pg_receivewal use the default of zlib instead (Z_DEFAULT_COMPRESSION).
The code in charge of finding the streaming start LSN when scanning the
existing archives is refactored and made more extensible. While on it,
rename "compression" to "compression_level" in walmethods.c, to reduce
the confusion with the introduction of the compression method, even if
the tar method used by pg_basebackup does not rely on the compression
method (yet, at least), but just on the compression level (this area
could be improved more, actually).
This is in preparation for an upcoming patch that adds LZ4 support to
pg_receivewal.
Author: Georgios Kokolatos
Reviewed-by: Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar,
Robert Haas
Discussion: https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me
2021-11-04 03:10:31 +01:00
|
|
|
</para>
|
|
|
|
<para>
|
Rework compression options of pg_receivewal
Since babbbb5 and the introduction of LZ4 in pg_receivewal, the
compression of the WAL archived is controlled by two options:
- --compression-method with "gzip", "none" or "lz4" as possible value.
- --compress=N to specify a compression level. This includes a
backward-incompatible change where a value of 0 leads to a failure
instead of no compression enforced.
This commit takes advantage of a4b5754 and 3603f7c to rework the
compression options of pg_receivewal, as of:
- The removal of --compression-method.
- The extenction of --compress to use the same grammar as pg_basebackup,
with a METHOD:DETAIL format, where a METHOD is "gzip", "none" or "lz4"
and a DETAIL is a comma-separated list of options, the only keyword
supported is now "level" to control the compression level. If only an
integer is specified as value of this option, "none" is implied on 0
and "gzip" is implied otherwise. This brings back --compress to be
backward-compatible with ~14, while still supporting LZ4.
This has also the advantage of centralizing the set of checks used by
pg_receivewal to validate its compression options.
Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/YlPQGNAAa04raObK@paquier.xyz
2022-04-13 04:09:51 +02:00
|
|
|
The compression method can be set to <literal>gzip</literal>,
|
|
|
|
<literal>lz4</literal> (if <productname>PostgreSQL</productname>
|
|
|
|
was compiled with <option>--with-lz4</option>) or
|
|
|
|
<literal>none</literal> for no compression.
|
|
|
|
A compression detail string can optionally be specified. If the
|
|
|
|
detail string is an integer, it specifies the compression level.
|
|
|
|
Otherwise, it should be a comma-separated list of items, each of the
|
|
|
|
form <literal>keyword</literal> or <literal>keyword=value</literal>.
|
|
|
|
Currently, the only supported keyword is <literal>level</literal>.
|
Rework compression options of pg_receivewal
pg_receivewal includes since cada1af the option --compress, to allow the
compression of WAL segments using gzip, with a value of 0 (the default)
meaning that no compression can be used.
This commit introduces a new option, called --compression-method, able
to use as values "none", the default, and "gzip", to make things more
extensible. The case of --compress=0 becomes fuzzy with this option
layer, so we have made the choice to make pg_receivewal return an error
when using "none" and a non-zero compression level, meaning that the
authorized values of --compress are now [1,9] instead of [0,9]. Not
specifying --compress with "gzip" as compression method makes
pg_receivewal use the default of zlib instead (Z_DEFAULT_COMPRESSION).
The code in charge of finding the streaming start LSN when scanning the
existing archives is refactored and made more extensible. While on it,
rename "compression" to "compression_level" in walmethods.c, to reduce
the confusion with the introduction of the compression method, even if
the tar method used by pg_basebackup does not rely on the compression
method (yet, at least), but just on the compression level (this area
could be improved more, actually).
This is in preparation for an upcoming patch that adds LZ4 support to
pg_receivewal.
Author: Georgios Kokolatos
Reviewed-by: Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar,
Robert Haas
Discussion: https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me
2021-11-04 03:10:31 +01:00
|
|
|
</para>
|
2017-01-17 12:10:26 +01:00
|
|
|
<para>
|
Rework compression options of pg_receivewal
Since babbbb5 and the introduction of LZ4 in pg_receivewal, the
compression of the WAL archived is controlled by two options:
- --compression-method with "gzip", "none" or "lz4" as possible value.
- --compress=N to specify a compression level. This includes a
backward-incompatible change where a value of 0 leads to a failure
instead of no compression enforced.
This commit takes advantage of a4b5754 and 3603f7c to rework the
compression options of pg_receivewal, as of:
- The removal of --compression-method.
- The extenction of --compress to use the same grammar as pg_basebackup,
with a METHOD:DETAIL format, where a METHOD is "gzip", "none" or "lz4"
and a DETAIL is a comma-separated list of options, the only keyword
supported is now "level" to control the compression level. If only an
integer is specified as value of this option, "none" is implied on 0
and "gzip" is implied otherwise. This brings back --compress to be
backward-compatible with ~14, while still supporting LZ4.
This has also the advantage of centralizing the set of checks used by
pg_receivewal to validate its compression options.
Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/YlPQGNAAa04raObK@paquier.xyz
2022-04-13 04:09:51 +02:00
|
|
|
If no compression level is specified, the default compression level
|
|
|
|
will be used. If only a level is specified without mentioning an
|
|
|
|
algorithm, <literal>gzip</literal> compression will be used if the
|
|
|
|
level is greater than 0, and no compression will be used if the level
|
|
|
|
is 0.
|
Rework compression options of pg_receivewal
pg_receivewal includes since cada1af the option --compress, to allow the
compression of WAL segments using gzip, with a value of 0 (the default)
meaning that no compression can be used.
This commit introduces a new option, called --compression-method, able
to use as values "none", the default, and "gzip", to make things more
extensible. The case of --compress=0 becomes fuzzy with this option
layer, so we have made the choice to make pg_receivewal return an error
when using "none" and a non-zero compression level, meaning that the
authorized values of --compress are now [1,9] instead of [0,9]. Not
specifying --compress with "gzip" as compression method makes
pg_receivewal use the default of zlib instead (Z_DEFAULT_COMPRESSION).
The code in charge of finding the streaming start LSN when scanning the
existing archives is refactored and made more extensible. While on it,
rename "compression" to "compression_level" in walmethods.c, to reduce
the confusion with the introduction of the compression method, even if
the tar method used by pg_basebackup does not rely on the compression
method (yet, at least), but just on the compression level (this area
could be improved more, actually).
This is in preparation for an upcoming patch that adds LZ4 support to
pg_receivewal.
Author: Georgios Kokolatos
Reviewed-by: Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar,
Robert Haas
Discussion: https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me
2021-11-04 03:10:31 +01:00
|
|
|
</para>
|
|
|
|
<para>
|
Rework compression options of pg_receivewal
Since babbbb5 and the introduction of LZ4 in pg_receivewal, the
compression of the WAL archived is controlled by two options:
- --compression-method with "gzip", "none" or "lz4" as possible value.
- --compress=N to specify a compression level. This includes a
backward-incompatible change where a value of 0 leads to a failure
instead of no compression enforced.
This commit takes advantage of a4b5754 and 3603f7c to rework the
compression options of pg_receivewal, as of:
- The removal of --compression-method.
- The extenction of --compress to use the same grammar as pg_basebackup,
with a METHOD:DETAIL format, where a METHOD is "gzip", "none" or "lz4"
and a DETAIL is a comma-separated list of options, the only keyword
supported is now "level" to control the compression level. If only an
integer is specified as value of this option, "none" is implied on 0
and "gzip" is implied otherwise. This brings back --compress to be
backward-compatible with ~14, while still supporting LZ4.
This has also the advantage of centralizing the set of checks used by
pg_receivewal to validate its compression options.
Author: Michael Paquier
Reviewed-by: Robert Haas, Georgios Kokolatos
Discussion: https://postgr.es/m/YlPQGNAAa04raObK@paquier.xyz
2022-04-13 04:09:51 +02:00
|
|
|
The suffix <filename>.gz</filename> will automatically be added to
|
|
|
|
all filenames when using <literal>gzip</literal>, and the suffix
|
|
|
|
<filename>.lz4</filename> is added when using <literal>lz4</literal>.
|
2017-01-17 12:10:26 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2011-10-26 20:13:33 +02:00
|
|
|
</variablelist>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The following command-line options control the database connection parameters.
|
|
|
|
|
|
|
|
<variablelist>
|
2013-02-25 13:48:27 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>-d <replaceable class="parameter">connstr</replaceable></option></term>
|
|
|
|
<term><option>--dbname=<replaceable class="parameter">connstr</replaceable></option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2020-10-03 04:19:31 +02:00
|
|
|
Specifies parameters used to connect to the server, as a <link
|
2020-11-11 01:18:35 +01:00
|
|
|
linkend="libpq-connstring">connection string</link>; these
|
2020-10-03 04:19:31 +02:00
|
|
|
will override any conflicting command line options.
|
2013-02-25 13:48:27 +01:00
|
|
|
</para>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The option is called <literal>--dbname</literal> for consistency with other
|
2017-02-09 22:23:46 +01:00
|
|
|
client applications, but because <application>pg_receivewal</application>
|
2013-02-25 13:48:27 +01:00
|
|
|
doesn't connect to any particular database in the cluster, database
|
|
|
|
name in the connection string will be ignored.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
<varlistentry>
|
|
|
|
<term><option>-h <replaceable class="parameter">host</replaceable></option></term>
|
|
|
|
<term><option>--host=<replaceable class="parameter">host</replaceable></option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies the host name of the machine on which the server is
|
|
|
|
running. If the value begins with a slash, it is used as the
|
|
|
|
directory for the Unix domain socket. The default is taken
|
|
|
|
from the <envar>PGHOST</envar> environment variable, if set,
|
|
|
|
else a Unix domain socket connection is attempted.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><option>-p <replaceable class="parameter">port</replaceable></option></term>
|
|
|
|
<term><option>--port=<replaceable class="parameter">port</replaceable></option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies the TCP port or local Unix domain socket file
|
|
|
|
extension on which the server is listening for connections.
|
|
|
|
Defaults to the <envar>PGPORT</envar> environment variable, if
|
|
|
|
set, or a compiled-in default.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><option>-U <replaceable>username</replaceable></option></term>
|
|
|
|
<term><option>--username=<replaceable class="parameter">username</replaceable></option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
User name to connect as.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 03:44:17 +02:00
|
|
|
<term><option>-w</option></term>
|
|
|
|
<term><option>--no-password</option></term>
|
2011-10-26 20:13:33 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Never issue a password prompt. If the server requires
|
|
|
|
password authentication and a password is not available by
|
|
|
|
other means such as a <filename>.pgpass</filename> file, the
|
|
|
|
connection attempt will fail. This option can be useful in
|
|
|
|
batch jobs and scripts where no user is present to enter a
|
|
|
|
password.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><option>-W</option></term>
|
|
|
|
<term><option>--password</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-02-09 22:23:46 +01:00
|
|
|
Force <application>pg_receivewal</application> to prompt for a
|
2011-10-26 20:13:33 +02:00
|
|
|
password before connecting to a database.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This option is never essential, since
|
2017-02-09 22:23:46 +01:00
|
|
|
<application>pg_receivewal</application> will automatically prompt
|
2011-10-26 20:13:33 +02:00
|
|
|
for a password if the server demands password authentication.
|
2017-02-09 22:23:46 +01:00
|
|
|
However, <application>pg_receivewal</application> will waste a
|
2011-10-26 20:13:33 +02:00
|
|
|
connection attempt finding out that the server wants a password.
|
2017-10-09 03:44:17 +02:00
|
|
|
In some cases it is worth typing <option>-W</option> to avoid the extra
|
2011-10-26 20:13:33 +02:00
|
|
|
connection attempt.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
|
|
|
|
2014-10-06 12:51:37 +02:00
|
|
|
<para>
|
2017-02-09 22:23:46 +01:00
|
|
|
<application>pg_receivewal</application> can perform one of the two
|
2014-10-06 12:51:37 +02:00
|
|
|
following actions in order to control physical replication slots:
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term><option>--create-slot</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Create a new physical replication slot with the name specified in
|
2015-08-10 13:28:18 +02:00
|
|
|
<option>--slot</option>, then exit.
|
2014-10-06 12:51:37 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><option>--drop-slot</option></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Drop the replication slot with the name specified in
|
|
|
|
<option>--slot</option>, then exit.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
<para>
|
2012-06-18 01:44:00 +02:00
|
|
|
Other options are also available:
|
2011-10-26 20:13:33 +02:00
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
2017-10-09 03:44:17 +02:00
|
|
|
<term><option>-V</option></term>
|
|
|
|
<term><option>--version</option></term>
|
2011-10-26 20:13:33 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-02-09 22:23:46 +01:00
|
|
|
Print the <application>pg_receivewal</application> version and exit.
|
2011-10-26 20:13:33 +02:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-10-09 03:44:17 +02:00
|
|
|
<term><option>-?</option></term>
|
|
|
|
<term><option>--help</option></term>
|
2011-10-26 20:13:33 +02:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-02-09 22:23:46 +01:00
|
|
|
Show help about <application>pg_receivewal</application> command line
|
2011-10-26 20:13:33 +02:00
|
|
|
arguments, and exit.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
</refsect1>
|
|
|
|
|
2017-08-16 02:26:58 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Exit Status</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<application>pg_receivewal</application> will exit with status 0 when
|
2022-09-14 16:32:24 +02:00
|
|
|
terminated by the <systemitem>SIGINT</systemitem> or
|
|
|
|
<systemitem>SIGTERM</systemitem> signal. (That is the
|
2017-08-16 02:26:58 +02:00
|
|
|
normal way to end it. Hence it is not an error.) For fatal errors or
|
|
|
|
other signals, the exit status will be nonzero.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
</refsect1>
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
<refsect1>
|
|
|
|
<title>Environment</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
This utility, like most other <productname>PostgreSQL</productname> utilities,
|
|
|
|
uses the environment variables supported by <application>libpq</application>
|
2017-11-23 15:39:47 +01:00
|
|
|
(see <xref linkend="libpq-envars"/>).
|
2011-10-26 20:13:33 +02:00
|
|
|
</para>
|
|
|
|
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
<para>
|
|
|
|
The environment variable <envar>PG_COLOR</envar> specifies whether to use
|
2020-03-09 02:53:22 +01:00
|
|
|
color in diagnostic messages. Possible values are
|
|
|
|
<literal>always</literal>, <literal>auto</literal> and
|
Unified logging system for command-line programs
This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
2019-04-01 14:24:37 +02:00
|
|
|
<literal>never</literal>.
|
|
|
|
</para>
|
2011-10-26 20:13:33 +02:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Notes</title>
|
|
|
|
|
|
|
|
<para>
|
2017-02-09 22:23:46 +01:00
|
|
|
When using <application>pg_receivewal</application> instead of
|
2022-09-17 11:34:20 +02:00
|
|
|
<xref linkend="guc-archive-command"/> or
|
2022-02-03 19:57:27 +01:00
|
|
|
<xref linkend="guc-archive-library"/> as the main WAL backup method, it is
|
2014-11-08 02:15:22 +01:00
|
|
|
strongly recommended to use replication slots. Otherwise, the server is
|
2017-05-12 17:49:56 +02:00
|
|
|
free to recycle or remove write-ahead log files before they are backed up,
|
2014-11-08 02:15:22 +01:00
|
|
|
because it does not have any information, either
|
2022-09-17 11:34:20 +02:00
|
|
|
from <xref linkend="guc-archive-command"/> or
|
|
|
|
<xref linkend="guc-archive-library"/> or the replication slots, about
|
2014-11-08 02:15:22 +01:00
|
|
|
how far the WAL stream has been archived. Note, however, that a
|
|
|
|
replication slot will fill up the server's disk space if the receiver does
|
|
|
|
not keep up with fetching the WAL data.
|
2011-10-26 20:13:33 +02:00
|
|
|
</para>
|
|
|
|
|
2018-04-07 23:45:39 +02:00
|
|
|
<para>
|
|
|
|
<application>pg_receivewal</application> will preserve group permissions on
|
|
|
|
the received WAL files if group permissions are enabled on the source
|
|
|
|
cluster.
|
|
|
|
</para>
|
|
|
|
|
2011-10-26 20:13:33 +02:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
|
|
|
|
|
|
|
<para>
|
2017-05-12 17:49:56 +02:00
|
|
|
To stream the write-ahead log from the server at
|
2011-10-26 20:13:33 +02:00
|
|
|
<literal>mydbserver</literal> and store it in the local directory
|
|
|
|
<filename>/usr/local/pgsql/archive</filename>:
|
2012-03-28 19:37:19 +02:00
|
|
|
<screen>
|
2017-02-09 22:23:46 +01:00
|
|
|
<prompt>$</prompt> <userinput>pg_receivewal -h mydbserver -D /usr/local/pgsql/archive</userinput>
|
2012-03-28 19:37:19 +02:00
|
|
|
</screen></para>
|
2011-10-26 20:13:33 +02:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
2017-11-23 15:39:47 +01:00
|
|
|
<member><xref linkend="app-pgbasebackup"/></member>
|
2011-10-26 20:13:33 +02:00
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
</refentry>
|