mirror of
https://github.com/postgres/postgres.git
synced 2025-07-27 12:41:57 +03:00
Replace "transaction log" with "write-ahead log"
This makes documentation and error messages match the renaming of "xlog" to "wal" in APIs and file naming.
This commit is contained in:
Peter Eisentraut
@ -1424,7 +1424,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
|
||||
As with base backups, the easiest way to produce a standalone
|
||||
hot backup is to use the <xref linkend="app-pgbasebackup">
|
||||
tool. If you include the <literal>-X</> parameter when calling
|
||||
it, all the transaction log required to use the backup will be
|
||||
it, all the write-ahead log required to use the backup will be
|
||||
included in the backup automatically, and no special action is
|
||||
required to restore the backup.
|
||||
</para>
|
||||
|
||||
@ -3312,7 +3312,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
|
||||
to the primary or upstream standby, where it can be seen using the
|
||||
<link linkend="monitoring-stats-views-table">
|
||||
<literal>pg_stat_replication</></link> view. The standby will report
|
||||
the last transaction log position it has written, the last position it
|
||||
the last write-ahead log position it has written, the last position it
|
||||
has flushed to disk, and the last position it has applied.
|
||||
This parameter's
|
||||
value is the maximum interval, in seconds, between reports. Updates are
|
||||
|
||||
@ -18466,21 +18466,21 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
<literal><function>pg_current_wal_flush_lsn()</function></literal>
|
||||
</entry>
|
||||
<entry><type>pg_lsn</type></entry>
|
||||
<entry>Get current transaction log flush location</entry>
|
||||
<entry>Get current write-ahead log flush location</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_current_wal_insert_lsn()</function></literal>
|
||||
</entry>
|
||||
<entry><type>pg_lsn</type></entry>
|
||||
<entry>Get current transaction log insert location</entry>
|
||||
<entry>Get current write-ahead log insert location</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_current_wal_lsn()</function></literal>
|
||||
</entry>
|
||||
<entry><type>pg_lsn</type></entry>
|
||||
<entry>Get current transaction log write location</entry>
|
||||
<entry>Get current write-ahead log write location</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
@ -18522,28 +18522,28 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
<literal><function>pg_switch_wal()</function></literal>
|
||||
</entry>
|
||||
<entry><type>pg_lsn</type></entry>
|
||||
<entry>Force switch to a new transaction log file (restricted to superusers by default, but other users can be granted EXECUTE to run the function)</entry>
|
||||
<entry>Force switch to a new write-ahead log file (restricted to superusers by default, but other users can be granted EXECUTE to run the function)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_walfile_name(<parameter>lsn</> <type>pg_lsn</>)</function></literal>
|
||||
</entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Convert transaction log location to file name</entry>
|
||||
<entry>Convert write-ahead log location to file name</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_walfile_name_offset(<parameter>lsn</> <type>pg_lsn</>)</function></literal>
|
||||
</entry>
|
||||
<entry><type>text</>, <type>integer</></entry>
|
||||
<entry>Convert transaction log location to file name and decimal byte offset within file</entry>
|
||||
<entry>Convert write-ahead log location to file name and decimal byte offset within file</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_wal_lsn_diff(<parameter>lsn</> <type>pg_lsn</>, <parameter>lsn</> <type>pg_lsn</>)</function></literal>
|
||||
</entry>
|
||||
<entry><type>numeric</></entry>
|
||||
<entry>Calculate the difference between two transaction log locations</entry>
|
||||
<entry>Calculate the difference between two write-ahead log locations</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -18556,7 +18556,7 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
backup label file (<filename>backup_label</>) and, if there are any links
|
||||
in the <filename>pg_tblspc/</> directory, a tablespace map file
|
||||
(<filename>tablespace_map</>) into the database cluster's data directory,
|
||||
performs a checkpoint, and then returns the backup's starting transaction
|
||||
performs a checkpoint, and then returns the backup's starting write-ahead
|
||||
log location as text. 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
|
||||
@ -18592,30 +18592,30 @@ postgres=# select pg_start_backup('label_goes_here');
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The function also creates a backup history file in the transaction log
|
||||
The 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</>, the starting and ending transaction log locations for
|
||||
<function>pg_start_backup</>, the starting and ending write-ahead log locations for
|
||||
the backup, and the starting and ending times of the backup. The return
|
||||
value is the backup's ending transaction log location (which again
|
||||
value is the backup's ending write-ahead log location (which again
|
||||
can be ignored). After recording the ending location, the current
|
||||
transaction log insertion
|
||||
point is automatically advanced to the next transaction log file, so that the
|
||||
ending transaction log file can be archived immediately to complete the backup.
|
||||
write-ahead log insertion
|
||||
point is automatically advanced to the next write-ahead log file, so that the
|
||||
ending write-ahead log file can be archived immediately to complete the backup.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>pg_switch_wal</> moves to the next transaction log file, allowing the
|
||||
<function>pg_switch_wal</> moves to the next write-ahead log file, allowing the
|
||||
current file to be archived (assuming you are using continuous archiving).
|
||||
The return value is the ending transaction log location + 1 within the just-completed transaction log file.
|
||||
If there has been no transaction log activity since the last transaction log switch,
|
||||
The return value is the ending write-ahead log location + 1 within the just-completed write-ahead log file.
|
||||
If there has been no write-ahead log activity since the last write-ahead log switch,
|
||||
<function>pg_switch_wal</> does nothing and returns the start location
|
||||
of the transaction log file currently in use.
|
||||
of the write-ahead log file currently in use.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>pg_create_restore_point</> creates a named transaction log
|
||||
<function>pg_create_restore_point</> creates a named write-ahead log
|
||||
record that can be used as recovery target, and returns the corresponding
|
||||
transaction log location. The given name can then be used with
|
||||
write-ahead log location. The given name can then be used with
|
||||
<xref linkend="recovery-target-name"> to specify the point up to which
|
||||
recovery will proceed. Avoid creating multiple restore points with the
|
||||
same name, since recovery will stop at the first one whose name matches
|
||||
@ -18623,16 +18623,16 @@ postgres=# select pg_start_backup('label_goes_here');
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>pg_current_wal_lsn</> displays the current transaction log write
|
||||
<function>pg_current_wal_lsn</> displays the current write-ahead log write
|
||||
location in the same format used by the above functions. Similarly,
|
||||
<function>pg_current_wal_insert_lsn</> displays the current transaction log
|
||||
<function>pg_current_wal_insert_lsn</> displays the current write-ahead log
|
||||
insertion location and <function>pg_current_wal_flush_lsn</> displays the
|
||||
current transaction log flush location. The insertion location is the <quote>logical</>
|
||||
current write-ahead log flush location. The insertion location is the <quote>logical</>
|
||||
end of the transaction log at any instant, while the write location is the end of
|
||||
what has actually been written out from the server's internal buffers and flush
|
||||
location is the location guaranteed to be written to durable storage. The write
|
||||
location is the end of what can be examined from outside the server, and is usually
|
||||
what you want if you are interested in archiving partially-complete transaction log
|
||||
what you want if you are interested in archiving partially-complete write-ahead log
|
||||
files. The insertion and flush locations are made available primarily for server
|
||||
debugging purposes. These are both read-only operations and do not
|
||||
require superuser permissions.
|
||||
@ -18640,7 +18640,7 @@ postgres=# select pg_start_backup('label_goes_here');
|
||||
|
||||
<para>
|
||||
You can use <function>pg_walfile_name_offset</> to extract the
|
||||
corresponding transaction log file name and byte offset from the results of any of the
|
||||
corresponding write-ahead log file name and byte offset from the results of any of the
|
||||
above functions. For example:
|
||||
<programlisting>
|
||||
postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
|
||||
@ -18649,17 +18649,17 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
|
||||
00000001000000000000000D | 4039624
|
||||
(1 row)
|
||||
</programlisting>
|
||||
Similarly, <function>pg_walfile_name</> extracts just the transaction log file name.
|
||||
When the given transaction log location is exactly at a transaction log file boundary, both
|
||||
these functions return the name of the preceding transaction log file.
|
||||
This is usually the desired behavior for managing transaction log archiving
|
||||
Similarly, <function>pg_walfile_name</> extracts just the write-ahead log file name.
|
||||
When the given write-ahead log location is exactly at a write-ahead log file boundary, both
|
||||
these functions return the name of the preceding write-ahead log file.
|
||||
This is usually the desired behavior for managing write-ahead log archiving
|
||||
behavior, since the preceding file is the last one that currently
|
||||
needs to be archived.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>pg_wal_lsn_diff</> calculates the difference in bytes
|
||||
between two transaction log locations. It can be used with
|
||||
between two write-ahead log locations. It can be used with
|
||||
<structname>pg_stat_replication</structname> or some functions shown in
|
||||
<xref linkend="functions-admin-backup-table"> to get the replication lag.
|
||||
</para>
|
||||
@ -18716,7 +18716,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
|
||||
<literal><function>pg_last_wal_receive_lsn()</function></literal>
|
||||
</entry>
|
||||
<entry><type>pg_lsn</type></entry>
|
||||
<entry>Get last transaction log location received and synced to disk by
|
||||
<entry>Get last write-ahead log location received and synced to disk by
|
||||
streaming replication. While streaming replication is in progress
|
||||
this will increase monotonically. If recovery has completed this will
|
||||
remain static at
|
||||
@ -18730,7 +18730,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
|
||||
<literal><function>pg_last_wal_replay_lsn()</function></literal>
|
||||
</entry>
|
||||
<entry><type>pg_lsn</type></entry>
|
||||
<entry>Get last transaction log location replayed during recovery.
|
||||
<entry>Get last write-ahead log location replayed during recovery.
|
||||
If recovery is still in progress this will increase monotonically.
|
||||
If recovery has completed then this value will remain static at
|
||||
the value of the last WAL record applied during that recovery.
|
||||
|
||||
@ -138,7 +138,7 @@ protocol to make nodes agree on a serializable transactional order.
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Transaction Log Shipping</term>
|
||||
<term>Write-Ahead Log Shipping</term>
|
||||
<listitem>
|
||||
|
||||
<para>
|
||||
@ -289,7 +289,7 @@ protocol to make nodes agree on a serializable transactional order.
|
||||
<entry>Feature</entry>
|
||||
<entry>Shared Disk Failover</entry>
|
||||
<entry>File System Replication</entry>
|
||||
<entry>Transaction Log Shipping</entry>
|
||||
<entry>Write-Ahead Log Shipping</entry>
|
||||
<entry>Trigger-Based Master-Standby Replication</entry>
|
||||
<entry>Statement-Based Replication Middleware</entry>
|
||||
<entry>Asynchronous Multimaster Replication</entry>
|
||||
@ -1036,7 +1036,7 @@ primary_slot_name = 'node_a_slot'
|
||||
<para>
|
||||
When requesting synchronous replication, each commit of a
|
||||
write transaction will wait until confirmation is
|
||||
received that the commit has been written to the transaction log on disk
|
||||
received that the commit has been written to the write-ahead log on disk
|
||||
of both the primary and standby server. The only possibility that data
|
||||
can be lost is if both the primary and the standby suffer crashes at the
|
||||
same time. This can provide a much higher level of durability, though only
|
||||
|
||||
@ -1032,7 +1032,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>CLogTruncationLock</></entry>
|
||||
<entry>Waiting to truncate the transaction log or waiting for transaction log truncation to finish.</entry>
|
||||
<entry>Waiting to truncate the write-ahead log or waiting for write-ahead log truncation to finish.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>clog</></entry>
|
||||
@ -1701,24 +1701,24 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||
<row>
|
||||
<entry><structfield>sent_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log location sent on this connection</entry>
|
||||
<entry>Last write-ahead log location sent on this connection</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>write_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log location written to disk by this standby
|
||||
<entry>Last write-ahead log location written to disk by this standby
|
||||
server</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>flush_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log location flushed to disk by this standby
|
||||
<entry>Last write-ahead log location flushed to disk by this standby
|
||||
server</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>replay_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log location replayed into the database on this
|
||||
<entry>Last write-ahead log location replayed into the database on this
|
||||
standby server</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1865,7 +1865,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||
<row>
|
||||
<entry><structfield>receive_start_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>First transaction log position used when WAL receiver is
|
||||
<entry>First write-ahead log position used when WAL receiver is
|
||||
started</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1876,14 +1876,14 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||
<row>
|
||||
<entry><structfield>received_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log position already received and flushed to
|
||||
<entry>Last write-ahead log position already received and flushed to
|
||||
disk, the initial value of this field being the first log position used
|
||||
when WAL receiver is started</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>received_tli</></entry>
|
||||
<entry><type>integer</></entry>
|
||||
<entry>Timeline number of last transaction log position received and
|
||||
<entry>Timeline number of last write-ahead log position received and
|
||||
flushed to disk, the initial value of this field being the timeline
|
||||
number of the first log position used when WAL receiver is started
|
||||
</entry>
|
||||
@ -1901,12 +1901,12 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||
<row>
|
||||
<entry><structfield>latest_end_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log position reported to origin WAL sender</entry>
|
||||
<entry>Last write-ahead log position reported to origin WAL sender</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>latest_end_time</></entry>
|
||||
<entry><type>timestamp with time zone</></entry>
|
||||
<entry>Time of last transaction log position reported to origin WAL sender</entry>
|
||||
<entry>Time of last write-ahead log position reported to origin WAL sender</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>slot_name</></entry>
|
||||
@ -1967,7 +1967,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||
<row>
|
||||
<entry><structfield>received_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log position received, the initial value of
|
||||
<entry>Last write-ahead log position received, the initial value of
|
||||
this field being 0</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1984,13 +1984,13 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
|
||||
<row>
|
||||
<entry><structfield>latest_end_lsn</></entry>
|
||||
<entry><type>pg_lsn</></entry>
|
||||
<entry>Last transaction log position reported to origin WAL sender
|
||||
<entry>Last write-ahead log position reported to origin WAL sender
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>latest_end_time</></entry>
|
||||
<entry><type>timestamp with time zone</></entry>
|
||||
<entry>Time of last transaction log position reported to origin WAL
|
||||
<entry>Time of last write-ahead log position reported to origin WAL
|
||||
sender</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
||||
@ -1547,7 +1547,7 @@ The commands accepted in walsender mode are:
|
||||
<listitem>
|
||||
<para>
|
||||
Current WAL flush location. Useful to get a known location in the
|
||||
transaction log where streaming can start.
|
||||
write-ahead log where streaming can start.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -242,7 +242,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This parameter specifies the LSN of the transaction log location up
|
||||
This parameter specifies the LSN of the write-ahead log location up
|
||||
to which recovery will proceed. The precise stopping point is also
|
||||
influenced by <xref linkend="recovery-target-inclusive">. This
|
||||
parameter is parsed using the system data type
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
|
||||
<refnamediv>
|
||||
<refname>CHECKPOINT</refname>
|
||||
<refpurpose>force a transaction log checkpoint</refpurpose>
|
||||
<refpurpose>force a write-ahead log checkpoint</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
@ -26,7 +26,7 @@ CHECKPOINT
|
||||
<title>Description</title>
|
||||
|
||||
<para>
|
||||
A checkpoint is a point in the transaction log sequence at which
|
||||
A checkpoint is a point in the write-ahead log sequence at which
|
||||
all data files have been updated to reflect the information in the
|
||||
log. All data files will be flushed to disk. Refer to
|
||||
<xref linkend="wal-configuration"> for more details about what happens
|
||||
|
||||
@ -320,7 +320,7 @@ PostgreSQL documentation
|
||||
<term><option>--waldir=<replaceable class="parameter">directory</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option specifies the directory where the transaction log
|
||||
This option specifies the directory where the write-ahead log
|
||||
should be stored.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -178,8 +178,8 @@ PostgreSQL documentation
|
||||
target directory, the tar contents will be written to
|
||||
standard output, suitable for piping to for example
|
||||
<productname>gzip</productname>. This is only possible if
|
||||
the cluster has no additional tablespaces and transaction
|
||||
log streaming is not used.
|
||||
the cluster has no additional tablespaces and WAL
|
||||
streaming is not used.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -299,9 +299,9 @@ PostgreSQL documentation
|
||||
<term><option>--waldir=<replaceable class="parameter">waldir</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the location for the transaction log directory.
|
||||
Specifies the location for the write-ahead log directory.
|
||||
<replaceable>waldir</replaceable> must be an absolute path.
|
||||
The transaction log directory can only be specified when
|
||||
The write-ahead log directory can only be specified when
|
||||
the backup is in plain mode.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -312,15 +312,15 @@ PostgreSQL documentation
|
||||
<term><option>--wal-method=<replaceable class="parameter">method</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Includes the required transaction log files (WAL files) in the
|
||||
backup. This will include all transaction logs generated during
|
||||
Includes the required write-ahead log files (WAL files) in the
|
||||
backup. This will include all write-ahead logs generated during
|
||||
the backup. Unless the method <literal>none</literal> is specified,
|
||||
it is possible to start a postmaster directly in the extracted
|
||||
directory without the need to consult the log archive, thus
|
||||
making this a completely standalone backup.
|
||||
</para>
|
||||
<para>
|
||||
The following methods for collecting the transaction logs are
|
||||
The following methods for collecting the write-ahead logs are
|
||||
supported:
|
||||
|
||||
<variablelist>
|
||||
@ -329,7 +329,7 @@ PostgreSQL documentation
|
||||
<term><literal>none</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Don't include transaction log in the backup.
|
||||
Don't include write-ahead log in the backup.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -339,7 +339,7 @@ PostgreSQL documentation
|
||||
<term><literal>fetch</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The transaction log files are collected at the end of the backup.
|
||||
The write-ahead log files are collected at the end of the backup.
|
||||
Therefore, it is necessary for the
|
||||
<xref linkend="guc-wal-keep-segments"> parameter to be set high
|
||||
enough that the log is not removed before the end of the backup.
|
||||
@ -347,7 +347,7 @@ PostgreSQL documentation
|
||||
backup will fail and be unusable.
|
||||
</para>
|
||||
<para>
|
||||
The transaction log files will be written to
|
||||
The write-ahead log files will be written to
|
||||
the <filename>base.tar</filename> file.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -358,16 +358,16 @@ PostgreSQL documentation
|
||||
<term><literal>stream</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Stream the transaction log while the backup is created. This will
|
||||
Stream the write-ahead log while the backup is created. This will
|
||||
open a second connection to the server and start streaming the
|
||||
transaction log in parallel while running the backup. Therefore,
|
||||
write-ahead log in parallel while running the backup. Therefore,
|
||||
it will use up two connections configured by the
|
||||
<xref linkend="guc-max-wal-senders"> parameter. As long as the
|
||||
client can keep up with transaction log received, using this mode
|
||||
requires no extra transaction logs to be saved on the master.
|
||||
client can keep up with write-ahead log received, using this mode
|
||||
requires no extra write-ahead logs to be saved on the master.
|
||||
</para>
|
||||
<para>
|
||||
The transaction log files are written to a separate file
|
||||
The write-ahead log files are written to a separate file
|
||||
named <filename>pg_wal.tar</filename> (if the server is a version
|
||||
earlier than 10, the file will be named <filename>pg_xlog.tar</filename>).
|
||||
</para>
|
||||
@ -443,7 +443,7 @@ PostgreSQL documentation
|
||||
By default, when <command>pg_basebackup</command> aborts with an
|
||||
error, it removes any directories it might have created before
|
||||
discovering that it cannot finish the job (for example, data directory
|
||||
and transaction log directory). This option inhibits tidying-up and is
|
||||
and write-ahead log directory). This option inhibits tidying-up and is
|
||||
thus useful for debugging.
|
||||
</para>
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ PostgreSQL documentation
|
||||
|
||||
<refnamediv>
|
||||
<refname>pg_receivewal</refname>
|
||||
<refpurpose>stream transaction logs from a <productname>PostgreSQL</productname> server</refpurpose>
|
||||
<refpurpose>stream write-ahead logs from a <productname>PostgreSQL</productname> server</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
@ -31,8 +31,8 @@ PostgreSQL documentation
|
||||
Description
|
||||
</title>
|
||||
<para>
|
||||
<application>pg_receivewal</application> is used to stream the transaction log
|
||||
from a running <productname>PostgreSQL</productname> cluster. The transaction
|
||||
<application>pg_receivewal</application> is used to stream the write-ahead log
|
||||
from a running <productname>PostgreSQL</productname> cluster. The write-ahead
|
||||
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
|
||||
@ -40,7 +40,7 @@ PostgreSQL documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<application>pg_receivewal</application> streams the transaction
|
||||
<application>pg_receivewal</application> streams the write-ahead
|
||||
log in real time as it's being generated on the server, and does not wait
|
||||
for segments to complete like <xref linkend="guc-archive-command"> does.
|
||||
For this reason, it is not necessary to set
|
||||
@ -56,7 +56,7 @@ PostgreSQL documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The transaction log is streamed over a regular
|
||||
The write-ahead log is streamed over a regular
|
||||
<productname>PostgreSQL</productname> connection and uses the replication
|
||||
protocol. The connection must be made with a superuser or a user
|
||||
having <literal>REPLICATION</literal> permissions (see
|
||||
@ -186,7 +186,7 @@ PostgreSQL documentation
|
||||
<term><option>--compress=<replaceable class="parameter">level</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enables gzip compression of transaction logs, and specifies the
|
||||
Enables gzip compression of write-ahead logs, and specifies the
|
||||
compression level (0 through 9, 0 being no compression and 9 being best
|
||||
compression). The suffix <filename>.gz</filename> will
|
||||
automatically be added to all filenames.
|
||||
@ -366,7 +366,7 @@ PostgreSQL documentation
|
||||
When using <application>pg_receivewal</application> instead of
|
||||
<xref linkend="guc-archive-command"> as the main WAL backup method, it is
|
||||
strongly recommended to use replication slots. Otherwise, the server is
|
||||
free to recycle or remove transaction log files before they are backed up,
|
||||
free to recycle or remove write-ahead log files before they are backed up,
|
||||
because it does not have any information, either
|
||||
from <xref linkend="guc-archive-command"> or the replication slots, about
|
||||
how far the WAL stream has been archived. Note, however, that a
|
||||
@ -380,7 +380,7 @@ PostgreSQL documentation
|
||||
<title>Examples</title>
|
||||
|
||||
<para>
|
||||
To stream the transaction log from the server at
|
||||
To stream the write-ahead log from the server at
|
||||
<literal>mydbserver</literal> and store it in the local directory
|
||||
<filename>/usr/local/pgsql/archive</filename>:
|
||||
<screen>
|
||||
|
||||
@ -614,7 +614,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
<term><option>--log-prefix=<replaceable>prefix</></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Set the filename prefix for the transaction log files created by
|
||||
Set the filename prefix for the log files created by
|
||||
<option>--log</>. The default is <literal>pgbench_log</>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -34,7 +34,7 @@
|
||||
problem. However, differences shown by
|
||||
<application>pg_test_fsync</application> might not make any significant
|
||||
difference in real database throughput, especially since many database servers
|
||||
are not speed-limited by their transaction logs.
|
||||
are not speed-limited by their write-ahead logs.
|
||||
<application>pg_test_fsync</application> reports average file sync operation
|
||||
time in microseconds for each <literal>wal_sync_method</literal>, which can also be used to
|
||||
inform efforts to optimize the value of <xref linkend="guc-commit-delay">.
|
||||
|
||||
@ -2517,7 +2517,7 @@
|
||||
2016-12-21 [ecbdc4c55] Forbid invalid combination of options in pg_basebackup.
|
||||
-->
|
||||
<para>
|
||||
Allow <application>pg_basebackup</> to stream transaction log in
|
||||
Allow <application>pg_basebackup</> to stream write-ahead log in
|
||||
tar mode (Magnus Hagander)
|
||||
</para>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user