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 thetransaction log required to use the backup will be

it, all thewrite-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>

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 lasttransaction log position it has written, the last position it

the lastwrite-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

<literal><function>pg_current_wal_flush_lsn()</function></literal>

</entry>

<entry><type>pg_lsn</type></entry>

<entry>Get currenttransaction log flush location</entry>

<entry>Get currentwrite-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 currenttransaction log insert location</entry>

<entry>Get currentwrite-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 currenttransaction log write location</entry>

<entry>Get currentwrite-ahead log write location</entry>

</row>

<row>

<entry>

<literal><function>pg_switch_wal()</function></literal>

</entry>

<entry><type>pg_lsn</type></entry>

<entry>Force switch to a newtransaction log file (restricted to superusers by default, but other users can be granted EXECUTE to run the function)</entry>

<entry>Force switch to a newwrite-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>Converttransaction log location to file name</entry>

<entry>Convertwrite-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>Converttransaction log location to file name and decimal byte offset within file</entry>

<entry>Convertwrite-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 twotransaction log locations</entry>

<entry>Calculate the difference between twowrite-ahead log locations</entry>

</row>

</tbody>

</tgroup>

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 startingtransaction

performs a checkpoint, and then returns the backup's startingwrite-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

</para>

<para>

The function also creates a backup history file in thetransaction log

The function also creates a backup history file in thewrite-ahead log

archive area. The history file includes the label given to

<function>pg_start_backup</>, the starting and endingtransaction log locations for

<function>pg_start_backup</>, the starting and endingwrite-ahead log locations for

the backup, and the starting and ending times of the backup. The return

value is the backup's endingtransaction log location (which again

value is the backup's endingwrite-ahead log location (which again

can be ignored). After recording the ending location, the current

transaction log insertion

point is automatically advanced to the nexttransaction log file, so that the

endingtransaction log file can be archived immediately to complete the backup.

write-ahead log insertion

point is automatically advanced to the nextwrite-ahead log file, so that the

endingwrite-ahead log file can be archived immediately to complete the backup.

</para>

<para>

<function>pg_switch_wal</> moves to the nexttransaction log file, allowing the

<function>pg_switch_wal</> moves to the nextwrite-ahead log file, allowing the

current file to be archived (assuming you are using continuous archiving).

The return value is the endingtransaction log location + 1 within the just-completedtransaction log file.

If there has been notransaction log activity since the lasttransaction log switch,

The return value is the endingwrite-ahead log location + 1 within the just-completedwrite-ahead log file.

If there has been nowrite-ahead log activity since the lastwrite-ahead log switch,

<function>pg_switch_wal</> does nothing and returns the start location

of thetransaction log file currently in use.

of thewrite-ahead log file currently in use.

</para>

<para>

<function>pg_create_restore_point</> creates a namedtransaction log

<function>pg_create_restore_point</> creates a namedwrite-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

the recovery target.

</para>

<para>

<function>pg_current_wal_lsn</> displays the currenttransaction log write

<function>pg_current_wal_lsn</> displays the currentwrite-ahead log write

location in the same format used by the above functions. Similarly,

<function>pg_current_wal_insert_lsn</> displays the currenttransaction log

<function>pg_current_wal_insert_lsn</> displays the currentwrite-ahead log

insertion location and <function>pg_current_wal_flush_lsn</> displays the

currenttransaction log flush location. The insertion location is the <quote>logical</>

currentwrite-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-completetransaction log

what you want if you are interested in archiving partially-completewrite-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.

</para>

<para>

You can use <function>pg_walfile_name_offset</> to extract the

correspondingtransaction log file name and byte offset from the results of any of the

correspondingwrite-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());

00000001000000000000000D | 4039624

(1 row)

</programlisting>

Similarly, <function>pg_walfile_name</> extracts just thetransaction log file name.

When the giventransaction log location is exactly at atransaction log file boundary, both

these functions return the name of the precedingtransaction log file.

This is usually the desired behavior for managingtransaction log archiving

Similarly, <function>pg_walfile_name</> extracts just thewrite-ahead log file name.

When the givenwrite-ahead log location is exactly at awrite-ahead log file boundary, both

these functions return the name of the precedingwrite-ahead log file.

This is usually the desired behavior for managingwrite-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 twotransaction log locations. It can be used with

between twowrite-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>

<literal><function>pg_last_wal_receive_lsn()</function></literal>

</entry>

<entry><type>pg_lsn</type></entry>

<entry>Get lasttransaction log location received and synced to disk by

<entry>Get lastwrite-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

<literal><function>pg_last_wal_replay_lsn()</function></literal>

</entry>

<entry><type>pg_lsn</type></entry>

<entry>Get lasttransaction log location replayed during recovery.

<entry>Get lastwrite-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.

</varlistentry>

<varlistentry>

<term>Transaction Log Shipping</term>

<term>Write-Ahead Log Shipping</term>

<listitem>

<para>

<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>

<para>

When requesting synchronous replication, each commit of a

write transaction will wait until confirmation is

received that the commit has been written to thetransaction log on disk

received that the commit has been written to thewrite-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

</row>

<row>

<entry><literal>CLogTruncationLock</></entry>

<entry>Waiting to truncate thetransaction log or waiting fortransaction log truncation to finish.</entry>

<entry>Waiting to truncate thewrite-ahead log or waiting forwrite-ahead log truncation to finish.</entry>

</row>

<row>

<entry><literal>clog</></entry>

<row>

<entry><structfield>sent_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log location sent on this connection</entry>

<entry>Lastwrite-ahead log location sent on this connection</entry>

</row>

<row>

<entry><structfield>write_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log location written to disk by this standby

<entry>Lastwrite-ahead log location written to disk by this standby

server</entry>

</row>

<row>

<entry><structfield>flush_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log location flushed to disk by this standby

<entry>Lastwrite-ahead log location flushed to disk by this standby

server</entry>

</row>

<row>

<entry><structfield>replay_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log location replayed into the database on this

<entry>Lastwrite-ahead log location replayed into the database on this

standby server</entry>

</row>

<row>

<row>

<entry><structfield>receive_start_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Firsttransaction log position used when WAL receiver is

<entry>Firstwrite-ahead log position used when WAL receiver is

started</entry>

</row>

<row>

<row>

<entry><structfield>received_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log position already received and flushed to

<entry>Lastwrite-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 lasttransaction log position received and

<entry>Timeline number of lastwrite-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>

<row>

<entry><structfield>latest_end_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log position reported to origin WAL sender</entry>

<entry>Lastwrite-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 lasttransaction log position reported to origin WAL sender</entry>

<entry>Time of lastwrite-ahead log position reported to origin WAL sender</entry>

</row>

<row>

<entry><structfield>slot_name</></entry>

<row>

<entry><structfield>received_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log position received, the initial value of

<entry>Lastwrite-ahead log position received, the initial value of

this field being 0</entry>

</row>

<row>

<row>

<entry><structfield>latest_end_lsn</></entry>

<entry><type>pg_lsn</></entry>

<entry>Lasttransaction log position reported to origin WAL sender

<entry>Lastwrite-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 lasttransaction log position reported to origin WAL

<entry>Time of lastwrite-ahead log position reported to origin WAL

sender</entry>

</row>

</tbody>

<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>

</term>

<listitem>

<para>

This parameter specifies the LSN of thetransaction log location up

This parameter specifies the LSN of thewrite-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

<refnamediv>

<refname>CHECKPOINT</refname>

<refpurpose>force atransaction log checkpoint</refpurpose>

<refpurpose>force awrite-ahead log checkpoint</refpurpose>

</refnamediv>

<refsynopsisdiv>

<title>Description</title>

<para>

A checkpoint is a point in thetransaction log sequence at which

A checkpoint is a point in thewrite-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

<term><option>--waldir=<replaceable class="parameter">directory</replaceable></option></term>

<listitem>

<para>

This option specifies the directory where thetransaction log

This option specifies the directory where thewrite-ahead log

should be stored.

</para>

</listitem>