summaryrefslogtreecommitdiffstats
path: root/doc/src/sgml/html/protocol-replication.html
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-13 13:44:03 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-13 13:44:03 +0000
commit293913568e6a7a86fd1479e1cff8e2ecb58d6568 (patch)
treefc3b469a3ec5ab71b36ea97cc7aaddb838423a0c /doc/src/sgml/html/protocol-replication.html
parentInitial commit. (diff)
downloadpostgresql-16-293913568e6a7a86fd1479e1cff8e2ecb58d6568.tar.xz
postgresql-16-293913568e6a7a86fd1479e1cff8e2ecb58d6568.zip
Adding upstream version 16.2.upstream/16.2
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/src/sgml/html/protocol-replication.html')
-rw-r--r--doc/src/sgml/html/protocol-replication.html538
1 files changed, 538 insertions, 0 deletions
diff --git a/doc/src/sgml/html/protocol-replication.html b/doc/src/sgml/html/protocol-replication.html
new file mode 100644
index 0000000..bb24eae
--- /dev/null
+++ b/doc/src/sgml/html/protocol-replication.html
@@ -0,0 +1,538 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>55.4. Streaming Replication Protocol</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="sasl-authentication.html" title="55.3. SASL Authentication" /><link rel="next" href="protocol-logical-replication.html" title="55.5. Logical Streaming Replication Protocol" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">55.4. Streaming Replication Protocol</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="sasl-authentication.html" title="55.3. SASL Authentication">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="protocol.html" title="Chapter 55. Frontend/Backend Protocol">Up</a></td><th width="60%" align="center">Chapter 55. Frontend/Backend Protocol</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.2 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="protocol-logical-replication.html" title="55.5. Logical Streaming Replication Protocol">Next</a></td></tr></table><hr /></div><div class="sect1" id="PROTOCOL-REPLICATION"><div class="titlepage"><div><div><h2 class="title" style="clear: both">55.4. Streaming Replication Protocol <a href="#PROTOCOL-REPLICATION" class="id_link">#</a></h2></div></div></div><p>
+ To initiate streaming replication, the frontend sends the
+ <code class="literal">replication</code> parameter in the startup message. A Boolean
+ value of <code class="literal">true</code> (or <code class="literal">on</code>,
+ <code class="literal">yes</code>, <code class="literal">1</code>) tells the backend to go into
+ physical replication walsender mode, wherein a small set of replication
+ commands, shown below, can be issued instead of SQL statements.
+ </p><p>
+ Passing <code class="literal">database</code> as the value for the
+ <code class="literal">replication</code> parameter instructs the backend to go into
+ logical replication walsender mode, connecting to the database specified in
+ the <code class="literal">dbname</code> parameter. In logical replication walsender
+ mode, the replication commands shown below as well as normal SQL commands can
+ be issued.
+ </p><p>
+ In either physical replication or logical replication walsender mode, only the
+ simple query protocol can be used.
+ </p><p>
+ For the purpose of testing replication commands, you can make a replication
+ connection via <span class="application">psql</span> or any other
+ <span class="application">libpq</span>-using tool with a connection string including
+ the <code class="literal">replication</code> option,
+ e.g.:
+</p><pre class="programlisting">
+psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
+</pre><p>
+ However, it is often more useful to use
+ <a class="xref" href="app-pgreceivewal.html" title="pg_receivewal"><span class="refentrytitle"><span class="application">pg_receivewal</span></span></a> (for physical replication) or
+ <a class="xref" href="app-pgrecvlogical.html" title="pg_recvlogical"><span class="refentrytitle"><span class="application">pg_recvlogical</span></span></a> (for logical replication).
+ </p><p>
+ Replication commands are logged in the server log when
+ <a class="xref" href="runtime-config-logging.html#GUC-LOG-REPLICATION-COMMANDS">log_replication_commands</a> is enabled.
+ </p><p>
+ The commands accepted in replication mode are:
+
+ </p><div class="variablelist"><dl class="variablelist"><dt id="PROTOCOL-REPLICATION-IDENTIFY-SYSTEM"><span class="term"><code class="literal">IDENTIFY_SYSTEM</code>
+ <a id="id-1.10.6.9.7.1.1.1.2" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-IDENTIFY-SYSTEM" class="id_link">#</a></dt><dd><p>
+ Requests the server to identify itself. Server replies with a result
+ set of a single row, containing four fields:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">systemid</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The unique system identifier identifying the cluster. This
+ can be used to check that the base backup used to initialize the
+ standby came from the same cluster.
+ </p></dd><dt><span class="term"><code class="literal">timeline</code> (<code class="type">int8</code>)</span></dt><dd><p>
+ Current timeline ID. Also useful to check that the standby is
+ consistent with the primary.
+ </p></dd><dt><span class="term"><code class="literal">xlogpos</code> (<code class="type">text</code>)</span></dt><dd><p>
+ Current WAL flush location. Useful to get a known location in the
+ write-ahead log where streaming can start.
+ </p></dd><dt><span class="term"><code class="literal">dbname</code> (<code class="type">text</code>)</span></dt><dd><p>
+ Database connected to or null.
+ </p></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-SHOW"><span class="term"><code class="literal">SHOW</code> <em class="replaceable"><code>name</code></em>
+ <a id="id-1.10.6.9.7.1.2.1.3" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-SHOW" class="id_link">#</a></dt><dd><p>
+ Requests the server to send the current setting of a run-time parameter.
+ This is similar to the SQL command <a class="xref" href="sql-show.html" title="SHOW"><span class="refentrytitle">SHOW</span></a>.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><em class="replaceable"><code>name</code></em></span></dt><dd><p>
+ The name of a run-time parameter. Available parameters are documented
+ in <a class="xref" href="runtime-config.html" title="Chapter 20. Server Configuration">Chapter 20</a>.
+ </p></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-TIMELINE-HISTORY"><span class="term"><code class="literal">TIMELINE_HISTORY</code> <em class="replaceable"><code>tli</code></em>
+ <a id="id-1.10.6.9.7.1.3.1.3" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-TIMELINE-HISTORY" class="id_link">#</a></dt><dd><p>
+ Requests the server to send over the timeline history file for timeline
+ <em class="replaceable"><code>tli</code></em>. Server replies with a
+ result set of a single row, containing two fields. While the fields
+ are labeled as <code class="type">text</code>, they effectively return raw bytes,
+ with no encoding conversion:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">filename</code> (<code class="type">text</code>)</span></dt><dd><p>
+ File name of the timeline history file, e.g., <code class="filename">00000002.history</code>.
+ </p></dd><dt><span class="term"><code class="literal">content</code> (<code class="type">text</code>)</span></dt><dd><p>
+ Contents of the timeline history file.
+ </p></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-CREATE-REPLICATION-SLOT"><span class="term"><code class="literal">CREATE_REPLICATION_SLOT</code> <em class="replaceable"><code>slot_name</code></em> [ <code class="literal">TEMPORARY</code> ] { <code class="literal">PHYSICAL</code> | <code class="literal">LOGICAL</code> <em class="replaceable"><code>output_plugin</code></em> } [ ( <em class="replaceable"><code>option</code></em> [, ...] ) ]
+ <a id="id-1.10.6.9.7.1.4.1.8" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-CREATE-REPLICATION-SLOT" class="id_link">#</a></dt><dd><p>
+ Create a physical or logical replication
+ slot. See <a class="xref" href="warm-standby.html#STREAMING-REPLICATION-SLOTS" title="27.2.6. Replication Slots">Section 27.2.6</a> for more about
+ replication slots.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><em class="replaceable"><code>slot_name</code></em></span></dt><dd><p>
+ The name of the slot to create. Must be a valid replication slot
+ name (see <a class="xref" href="warm-standby.html#STREAMING-REPLICATION-SLOTS-MANIPULATION" title="27.2.6.1. Querying and Manipulating Replication Slots">Section 27.2.6.1</a>).
+ </p></dd><dt><span class="term"><em class="replaceable"><code>output_plugin</code></em></span></dt><dd><p>
+ The name of the output plugin used for logical decoding
+ (see <a class="xref" href="logicaldecoding-output-plugin.html" title="49.6. Logical Decoding Output Plugins">Section 49.6</a>).
+ </p></dd><dt><span class="term"><code class="literal">TEMPORARY</code></span></dt><dd><p>
+ Specify that this replication slot is a temporary one. Temporary
+ slots are not saved to disk and are automatically dropped on error
+ or when the session has finished.
+ </p></dd></dl></div><p>The following options are supported:</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">TWO_PHASE [ <em class="replaceable"><code>boolean</code></em> ]</code></span></dt><dd><p>
+ If true, this logical replication slot supports decoding of two-phase
+ commit. With this option, commands related to two-phase commit such as
+ <code class="literal">PREPARE TRANSACTION</code>, <code class="literal">COMMIT PREPARED</code>
+ and <code class="literal">ROLLBACK PREPARED</code> are decoded and transmitted.
+ The transaction will be decoded and transmitted at
+ <code class="literal">PREPARE TRANSACTION</code> time.
+ The default is false.
+ </p></dd><dt><span class="term"><code class="literal">RESERVE_WAL [ <em class="replaceable"><code>boolean</code></em> ]</code></span></dt><dd><p>
+ If true, this physical replication slot reserves <acronym class="acronym">WAL</acronym>
+ immediately. Otherwise, <acronym class="acronym">WAL</acronym> is only reserved upon
+ connection from a streaming replication client.
+ The default is false.
+ </p></dd><dt><span class="term"><code class="literal">SNAPSHOT { 'export' | 'use' | 'nothing' }</code></span></dt><dd><p>
+ Decides what to do with the snapshot created during logical slot
+ initialization. <code class="literal">'export'</code>, which is the default,
+ will export the snapshot for use in other sessions. This option can't
+ be used inside a transaction. <code class="literal">'use'</code> will use the
+ snapshot for the current transaction executing the command. This
+ option must be used in a transaction, and
+ <code class="literal">CREATE_REPLICATION_SLOT</code> must be the first command
+ run in that transaction. Finally, <code class="literal">'nothing'</code> will
+ just use the snapshot for logical decoding as normal but won't do
+ anything else with it.
+ </p></dd></dl></div><p>
+ In response to this command, the server will send a one-row result set
+ containing the following fields:
+
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">slot_name</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The name of the newly-created replication slot.
+ </p></dd><dt><span class="term"><code class="literal">consistent_point</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The WAL location at which the slot became consistent. This is the
+ earliest location from which streaming can start on this replication
+ slot.
+ </p></dd><dt><span class="term"><code class="literal">snapshot_name</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The identifier of the snapshot exported by the command. The
+ snapshot is valid until a new command is executed on this connection
+ or the replication connection is closed. Null if the created slot
+ is physical.
+ </p></dd><dt><span class="term"><code class="literal">output_plugin</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The name of the output plugin used by the newly-created replication
+ slot. Null if the created slot is physical.
+ </p></dd></dl></div><p>
+ </p></dd><dt id="PROTOCOL-REPLICATION-CREATE-REPLICATION-SLOT-LEGACY"><span class="term"><code class="literal">CREATE_REPLICATION_SLOT</code> <em class="replaceable"><code>slot_name</code></em> [ <code class="literal">TEMPORARY</code> ] { <code class="literal">PHYSICAL</code> [ <code class="literal">RESERVE_WAL</code> ] | <code class="literal">LOGICAL</code> <em class="replaceable"><code>output_plugin</code></em> [ <code class="literal">EXPORT_SNAPSHOT</code> | <code class="literal">NOEXPORT_SNAPSHOT</code> | <code class="literal">USE_SNAPSHOT</code> | <code class="literal">TWO_PHASE</code> ] }
+ </span> <a href="#PROTOCOL-REPLICATION-CREATE-REPLICATION-SLOT-LEGACY" class="id_link">#</a></dt><dd><p>
+ For compatibility with older releases, this alternative syntax for
+ the <code class="literal">CREATE_REPLICATION_SLOT</code> command is still supported.
+ </p></dd><dt id="PROTOCOL-REPLICATION-READ-REPLICATION-SLOT"><span class="term"><code class="literal">READ_REPLICATION_SLOT</code> <em class="replaceable"><code>slot_name</code></em>
+ <a id="id-1.10.6.9.7.1.6.1.3" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-READ-REPLICATION-SLOT" class="id_link">#</a></dt><dd><p>
+ Read some information associated with a replication slot. Returns a tuple
+ with <code class="literal">NULL</code> values if the replication slot does not
+ exist. This command is currently only supported for physical replication
+ slots.
+ </p><p>
+ In response to this command, the server will return a one-row result set,
+ containing the following fields:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">slot_type</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The replication slot's type, either <code class="literal">physical</code> or
+ <code class="literal">NULL</code>.
+ </p></dd><dt><span class="term"><code class="literal">restart_lsn</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The replication slot's <code class="literal">restart_lsn</code>.
+ </p></dd><dt><span class="term"><code class="literal">restart_tli</code> (<code class="type">int8</code>)</span></dt><dd><p>
+ The timeline ID associated with <code class="literal">restart_lsn</code>,
+ following the current timeline history.
+ </p></dd></dl></div><p>
+ </p></dd><dt id="PROTOCOL-REPLICATION-START-REPLICATION"><span class="term"><code class="literal">START_REPLICATION</code> [ <code class="literal">SLOT</code> <em class="replaceable"><code>slot_name</code></em> ] [ <code class="literal">PHYSICAL</code> ] <em class="replaceable"><code>XXX/XXX</code></em> [ <code class="literal">TIMELINE</code> <em class="replaceable"><code>tli</code></em> ]
+ <a id="id-1.10.6.9.7.1.7.1.8" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-START-REPLICATION" class="id_link">#</a></dt><dd><p>
+ Instructs server to start streaming WAL, starting at
+ WAL location <em class="replaceable"><code>XXX/XXX</code></em>.
+ If <code class="literal">TIMELINE</code> option is specified,
+ streaming starts on timeline <em class="replaceable"><code>tli</code></em>;
+ otherwise, the server's current timeline is selected. The server can
+ reply with an error, for example if the requested section of WAL has already
+ been recycled. On success, the server responds with a CopyBothResponse
+ message, and then starts to stream WAL to the frontend.
+ </p><p>
+ If a slot's name is provided
+ via <em class="replaceable"><code>slot_name</code></em>, it will be updated
+ as replication progresses so that the server knows which WAL segments,
+ and if <code class="varname">hot_standby_feedback</code> is on which transactions,
+ are still needed by the standby.
+ </p><p>
+ If the client requests a timeline that's not the latest but is part of
+ the history of the server, the server will stream all the WAL on that
+ timeline starting from the requested start point up to the point where
+ the server switched to another timeline. If the client requests
+ streaming at exactly the end of an old timeline, the server skips COPY
+ mode entirely.
+ </p><p>
+ After streaming all the WAL on a timeline that is not the latest one,
+ the server will end streaming by exiting the COPY mode. When the client
+ acknowledges this by also exiting COPY mode, the server sends a result
+ set with one row and two columns, indicating the next timeline in this
+ server's history. The first column is the next timeline's ID (type <code class="type">int8</code>), and the
+ second column is the WAL location where the switch happened (type <code class="type">text</code>). Usually,
+ the switch position is the end of the WAL that was streamed, but there
+ are corner cases where the server can send some WAL from the old
+ timeline that it has not itself replayed before promoting. Finally, the
+ server sends two CommandComplete messages (one that ends the CopyData
+ and the other ends the <code class="literal">START_REPLICATION</code> itself), and
+ is ready to accept a new command.
+ </p><p>
+ WAL data is sent as a series of CopyData messages. (This allows
+ other information to be intermixed; in particular the server can send
+ an ErrorResponse message if it encounters a failure after beginning
+ to stream.) The payload of each CopyData message from server to the
+ client contains a message of one of the following formats:
+ </p><div class="variablelist"><dl class="variablelist"><dt id="PROTOCOL-REPLICATION-XLOGDATA"><span class="term">XLogData (B)</span> <a href="#PROTOCOL-REPLICATION-XLOGDATA" class="id_link">#</a></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('w')</span></dt><dd><p>
+ Identifies the message as WAL data.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The starting point of the WAL data in this message.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The current end of WAL on the server.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The server's system clock at the time of transmission, as
+ microseconds since midnight on 2000-01-01.
+ </p></dd><dt><span class="term">Byte<em class="replaceable"><code>n</code></em></span></dt><dd><p>
+ A section of the WAL data stream.
+ </p><p>
+ A single WAL record is never split across two XLogData messages.
+ When a WAL record crosses a WAL page boundary, and is therefore
+ already split using continuation records, it can be split at the page
+ boundary. In other words, the first main WAL record and its
+ continuation records can be sent in different XLogData messages.
+ </p></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-PRIMARY-KEEPALIVE-MESSAGE"><span class="term">Primary keepalive message (B)</span> <a href="#PROTOCOL-REPLICATION-PRIMARY-KEEPALIVE-MESSAGE" class="id_link">#</a></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('k')</span></dt><dd><p>
+ Identifies the message as a sender keepalive.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The current end of WAL on the server.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The server's system clock at the time of transmission, as
+ microseconds since midnight on 2000-01-01.
+ </p></dd><dt><span class="term">Byte1</span></dt><dd><p>
+ 1 means that the client should reply to this message as soon as
+ possible, to avoid a timeout disconnect. 0 otherwise.
+ </p></dd></dl></div></dd></dl></div><p>
+ The receiving process can send replies back to the sender at any time,
+ using one of the following message formats (also in the payload of a
+ CopyData message):
+ </p><div class="variablelist"><dl class="variablelist"><dt id="PROTOCOL-REPLICATION-STANDBY-STATUS-UPDATE"><span class="term">Standby status update (F)</span> <a href="#PROTOCOL-REPLICATION-STANDBY-STATUS-UPDATE" class="id_link">#</a></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('r')</span></dt><dd><p>
+ Identifies the message as a receiver status update.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The location of the last WAL byte + 1 received and written to disk
+ in the standby.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The location of the last WAL byte + 1 flushed to disk in
+ the standby.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The location of the last WAL byte + 1 applied in the standby.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The client's system clock at the time of transmission, as
+ microseconds since midnight on 2000-01-01.
+ </p></dd><dt><span class="term">Byte1</span></dt><dd><p>
+ If 1, the client requests the server to reply to this message
+ immediately. This can be used to ping the server, to test if
+ the connection is still healthy.
+ </p></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-HOT-STANDBY-FEEDBACK-MESSAGE"><span class="term">Hot standby feedback message (F)</span> <a href="#PROTOCOL-REPLICATION-HOT-STANDBY-FEEDBACK-MESSAGE" class="id_link">#</a></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('h')</span></dt><dd><p>
+ Identifies the message as a hot standby feedback message.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The client's system clock at the time of transmission, as
+ microseconds since midnight on 2000-01-01.
+ </p></dd><dt><span class="term">Int32</span></dt><dd><p>
+ The standby's current global xmin, excluding the catalog_xmin from any
+ replication slots. If both this value and the following
+ catalog_xmin are 0 this is treated as a notification that hot standby
+ feedback will no longer be sent on this connection. Later non-zero
+ messages may reinitiate the feedback mechanism.
+ </p></dd><dt><span class="term">Int32</span></dt><dd><p>
+ The epoch of the global xmin xid on the standby.
+ </p></dd><dt><span class="term">Int32</span></dt><dd><p>
+ The lowest catalog_xmin of any replication slots on the standby. Set to 0
+ if no catalog_xmin exists on the standby or if hot standby feedback is being
+ disabled.
+ </p></dd><dt><span class="term">Int32</span></dt><dd><p>
+ The epoch of the catalog_xmin xid on the standby.
+ </p></dd></dl></div></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-START-REPLICATION-SLOT-LOGICAL"><span class="term"><code class="literal">START_REPLICATION</code> <code class="literal">SLOT</code> <em class="replaceable"><code>slot_name</code></em> <code class="literal">LOGICAL</code> <em class="replaceable"><code>XXX/XXX</code></em> [ ( <em class="replaceable"><code>option_name</code></em> [ <em class="replaceable"><code>option_value</code></em> ] [, ...] ) ]</span> <a href="#PROTOCOL-REPLICATION-START-REPLICATION-SLOT-LOGICAL" class="id_link">#</a></dt><dd><p>
+ Instructs server to start streaming WAL for logical replication,
+ starting at either WAL location <em class="replaceable"><code>XXX/XXX</code></em> or the slot's
+ <code class="literal">confirmed_flush_lsn</code> (see <a class="xref" href="view-pg-replication-slots.html" title="54.19. pg_replication_slots">Section 54.19</a>), whichever is greater. This
+ behavior makes it easier for clients to avoid updating their local LSN
+ status when there is no data to process. However, starting at a
+ different LSN than requested might not catch certain kinds of client
+ errors; so the client may wish to check that
+ <code class="literal">confirmed_flush_lsn</code> matches its expectations before
+ issuing <code class="literal">START_REPLICATION</code>.
+ </p><p>
+ The server can reply with an error, for example if the
+ slot does not exist. On success, the server responds with a CopyBothResponse
+ message, and then starts to stream WAL to the frontend.
+ </p><p>
+ The messages inside the CopyBothResponse messages are of the same format
+ documented for <code class="literal">START_REPLICATION ... PHYSICAL</code>, including
+ two CommandComplete messages.
+ </p><p>
+ The output plugin associated with the selected slot is used
+ to process the output for streaming.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">SLOT</code> <em class="replaceable"><code>slot_name</code></em></span></dt><dd><p>
+ The name of the slot to stream changes from. This parameter is required,
+ and must correspond to an existing logical replication slot created
+ with <code class="literal">CREATE_REPLICATION_SLOT</code> in
+ <code class="literal">LOGICAL</code> mode.
+ </p></dd><dt><span class="term"><em class="replaceable"><code>XXX/XXX</code></em></span></dt><dd><p>
+ The WAL location to begin streaming at.
+ </p></dd><dt><span class="term"><em class="replaceable"><code>option_name</code></em></span></dt><dd><p>
+ The name of an option passed to the slot's logical decoding output
+ plugin. See <a class="xref" href="protocol-logical-replication.html" title="55.5. Logical Streaming Replication Protocol">Section 55.5</a> for
+ options that are accepted by the standard (<code class="literal">pgoutput</code>)
+ plugin.
+ </p></dd><dt><span class="term"><em class="replaceable"><code>option_value</code></em></span></dt><dd><p>
+ Optional value, in the form of a string constant, associated with the
+ specified option.
+ </p></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-DROP-REPLICATION-SLOT"><span class="term">
+ <code class="literal">DROP_REPLICATION_SLOT</code> <em class="replaceable"><code>slot_name</code></em> [<span class="optional"> <code class="literal">WAIT</code> </span>]
+ <a id="id-1.10.6.9.7.1.9.1.4" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-DROP-REPLICATION-SLOT" class="id_link">#</a></dt><dd><p>
+ Drops a replication slot, freeing any reserved server-side resources.
+ If the slot is a logical slot that was created in a database other than
+ the database the walsender is connected to, this command fails.
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><em class="replaceable"><code>slot_name</code></em></span></dt><dd><p>
+ The name of the slot to drop.
+ </p></dd><dt><span class="term"><code class="literal">WAIT</code></span></dt><dd><p>
+ This option causes the command to wait if the slot is active until
+ it becomes inactive, instead of the default behavior of raising an
+ error.
+ </p></dd></dl></div></dd><dt id="PROTOCOL-REPLICATION-BASE-BACKUP"><span class="term"><code class="literal">BASE_BACKUP</code> [ ( <em class="replaceable"><code>option</code></em> [, ...] ) ]
+ <a id="id-1.10.6.9.7.1.10.1.3" class="indexterm"></a>
+ </span> <a href="#PROTOCOL-REPLICATION-BASE-BACKUP" class="id_link">#</a></dt><dd><p>
+ Instructs the server to start streaming a base backup.
+ The system will automatically be put in backup mode before the backup
+ is started, and taken out of it when the backup is complete. The
+ following options are accepted:
+
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">LABEL</code> <em class="replaceable"><code>'label'</code></em></span></dt><dd><p>
+ Sets the label of the backup. If none is specified, a backup label
+ of <code class="literal">base backup</code> will be used. The quoting rules
+ for the label are the same as a standard SQL string with
+ <a class="xref" href="runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS">standard_conforming_strings</a> turned on.
+ </p></dd><dt><span class="term"><code class="literal">TARGET</code> <em class="replaceable"><code>'target'</code></em></span></dt><dd><p>
+ Tells the server where to send the backup. If the target is
+ <code class="literal">client</code>, which is the default, the backup data is
+ sent to the client. If it is <code class="literal">server</code>, the backup
+ data is written to the server at the pathname specified by the
+ <code class="literal">TARGET_DETAIL</code> option. If it is
+ <code class="literal">blackhole</code>, the backup data is not sent
+ anywhere; it is simply discarded.
+ </p><p>
+ The <code class="literal">server</code> target requires superuser privilege or
+ being granted the <code class="literal">pg_write_server_files</code> role.
+ </p></dd><dt><span class="term"><code class="literal">TARGET_DETAIL</code> <em class="replaceable"><code>'detail'</code></em></span></dt><dd><p>
+ Provides additional information about the backup target.
+ </p><p>
+ Currently, this option can only be used when the backup target is
+ <code class="literal">server</code>. It specifies the server directory
+ to which the backup should be written.
+ </p></dd><dt><span class="term"><code class="literal">PROGRESS [ <em class="replaceable"><code>boolean</code></em> ]</code></span></dt><dd><p>
+ If set to true, request information required to generate a progress
+ report. This will send back an approximate size in the header of each
+ tablespace, which can be used to calculate how far along the stream
+ is done. This is calculated by enumerating all the file sizes once
+ before the transfer is even started, and might as such have a
+ negative impact on the performance. In particular, it might take
+ longer before the first data
+ is streamed. Since the database files can change during the backup,
+ the size is only approximate and might both grow and shrink between
+ the time of approximation and the sending of the actual files.
+ The default is false.
+ </p></dd><dt><span class="term"><code class="literal">CHECKPOINT { 'fast' | 'spread' }</code></span></dt><dd><p>
+ Sets the type of checkpoint to be performed at the beginning of the
+ base backup. The default is <code class="literal">spread</code>.
+ </p></dd><dt><span class="term"><code class="literal">WAL [ <em class="replaceable"><code>boolean</code></em> ]</code></span></dt><dd><p>
+ If set to true, include the necessary WAL segments in the backup.
+ This will include all the files between start and stop backup in the
+ <code class="filename">pg_wal</code> directory of the base directory tar
+ file. The default is false.
+ </p></dd><dt><span class="term"><code class="literal">WAIT [ <em class="replaceable"><code>boolean</code></em> ]</code></span></dt><dd><p>
+ If set to true, the backup will wait until the last required WAL
+ segment has been archived, or emit a warning if WAL archiving is
+ not enabled. If false, the backup will neither wait nor warn,
+ leaving the client responsible for ensuring the required log is
+ available. The default is true.
+ </p></dd><dt><span class="term"><code class="literal">COMPRESSION</code> <em class="replaceable"><code>'method'</code></em></span></dt><dd><p>
+ Instructs the server to compress the backup using the specified
+ method. Currently, the supported methods are <code class="literal">gzip</code>,
+ <code class="literal">lz4</code>, and <code class="literal">zstd</code>.
+ </p></dd><dt><span class="term"><code class="literal">COMPRESSION_DETAIL</code> <em class="replaceable"><code>detail</code></em></span></dt><dd><p>
+ Specifies details for the chosen compression method. This should only
+ be used in conjunction with the <code class="literal">COMPRESSION</code>
+ option. If the value is an integer, it specifies the compression
+ level. Otherwise, it should be a comma-separated list of items,
+ each of the form <em class="replaceable"><code>keyword</code></em> or
+ <em class="replaceable"><code>keyword=value</code></em>. Currently, the supported
+ keywords are <code class="literal">level</code>, <code class="literal">long</code> and
+ <code class="literal">workers</code>.
+ </p><p>
+ The <code class="literal">level</code> keyword sets the compression level.
+ For <code class="literal">gzip</code> the compression level should be an
+ integer between <code class="literal">1</code> and <code class="literal">9</code>
+ (default <code class="literal">Z_DEFAULT_COMPRESSION</code> or
+ <code class="literal">-1</code>), for <code class="literal">lz4</code> an integer
+ between 1 and 12 (default <code class="literal">0</code> for fast compression
+ mode), and for <code class="literal">zstd</code> an integer between
+ <code class="literal">ZSTD_minCLevel()</code> (usually <code class="literal">-131072</code>)
+ and <code class="literal">ZSTD_maxCLevel()</code> (usually <code class="literal">22</code>),
+ (default <code class="literal">ZSTD_CLEVEL_DEFAULT</code> or
+ <code class="literal">3</code>).
+ </p><p>
+ The <code class="literal">long</code> keyword enables long-distance matching
+ mode, for improved compression ratio, at the expense of higher memory
+ use. Long-distance mode is supported only for
+ <code class="literal">zstd</code>.
+ </p><p>
+ The <code class="literal">workers</code> keyword sets the number of threads
+ that should be used for parallel compression. Parallel compression
+ is supported only for <code class="literal">zstd</code>.
+ </p></dd><dt><span class="term"><code class="literal">MAX_RATE</code> <em class="replaceable"><code>rate</code></em></span></dt><dd><p>
+ Limit (throttle) the maximum amount of data transferred from server
+ to client per unit of time. The expected unit is kilobytes per second.
+ If this option is specified, the value must either be equal to zero
+ or it must fall within the range from 32 kB through 1 GB (inclusive).
+ If zero is passed or the option is not specified, no restriction is
+ imposed on the transfer.
+ </p></dd><dt><span class="term"><code class="literal">TABLESPACE_MAP [ <em class="replaceable"><code>boolean</code></em> ]</code></span></dt><dd><p>
+ If true, include information about symbolic links present in the
+ directory <code class="filename">pg_tblspc</code> in a file named
+ <code class="filename">tablespace_map</code>. The tablespace map file includes
+ each symbolic link name as it exists in the directory
+ <code class="filename">pg_tblspc/</code> and the full path of that symbolic link.
+ The default is false.
+ </p></dd><dt><span class="term"><code class="literal">VERIFY_CHECKSUMS [ <em class="replaceable"><code>boolean</code></em> ]</code></span></dt><dd><p>
+ If true, checksums are verified during a base backup if they are
+ enabled. If false, this is skipped. The default is true.
+ </p></dd><dt><span class="term"><code class="literal">MANIFEST</code> <em class="replaceable"><code>manifest_option</code></em></span></dt><dd><p>
+ When this option is specified with a value of <code class="literal">yes</code>
+ or <code class="literal">force-encode</code>, a backup manifest is created
+ and sent along with the backup. The manifest is a list of every
+ file present in the backup with the exception of any WAL files that
+ may be included. It also stores the size, last modification time, and
+ optionally a checksum for each file.
+ A value of <code class="literal">force-encode</code> forces all filenames
+ to be hex-encoded; otherwise, this type of encoding is performed only
+ for files whose names are non-UTF8 octet sequences.
+ <code class="literal">force-encode</code> is intended primarily for testing
+ purposes, to be sure that clients which read the backup manifest
+ can handle this case. For compatibility with previous releases,
+ the default is <code class="literal">MANIFEST 'no'</code>.
+ </p></dd><dt><span class="term"><code class="literal">MANIFEST_CHECKSUMS</code> <em class="replaceable"><code>checksum_algorithm</code></em></span></dt><dd><p>
+ Specifies the checksum algorithm that should be applied to each file included
+ in the backup manifest. Currently, the available
+ algorithms are <code class="literal">NONE</code>, <code class="literal">CRC32C</code>,
+ <code class="literal">SHA224</code>, <code class="literal">SHA256</code>,
+ <code class="literal">SHA384</code>, and <code class="literal">SHA512</code>.
+ The default is <code class="literal">CRC32C</code>.
+ </p></dd></dl></div><p>
+ </p><p>
+ When the backup is started, the server will first send two
+ ordinary result sets, followed by one or more CopyOutResponse
+ results.
+ </p><p>
+ The first ordinary result set contains the starting position of the
+ backup, in a single row with two columns. The first column contains
+ the start position given in XLogRecPtr format, and the second column
+ contains the corresponding timeline ID.
+ </p><p>
+ The second ordinary result set has one row for each tablespace.
+ The fields in this row are:
+
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">spcoid</code> (<code class="type">oid</code>)</span></dt><dd><p>
+ The OID of the tablespace, or null if it's the base
+ directory.
+ </p></dd><dt><span class="term"><code class="literal">spclocation</code> (<code class="type">text</code>)</span></dt><dd><p>
+ The full path of the tablespace directory, or null
+ if it's the base directory.
+ </p></dd><dt><span class="term"><code class="literal">size</code> (<code class="type">int8</code>)</span></dt><dd><p>
+ The approximate size of the tablespace, in kilobytes (1024 bytes),
+ if progress report has been requested; otherwise it's null.
+ </p></dd></dl></div><p>
+ </p><p>
+ After the second regular result set, a CopyOutResponse will be sent.
+ The payload of each CopyData message will contain a message in one of
+ the following formats:
+ </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">new archive (B)</span></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('n')</span></dt><dd><p>
+ Identifies the message as indicating the start of a new archive.
+ There will be one archive for the main data directory and one
+ for each additional tablespace; each will use tar format
+ (following the <span class="quote">“<span class="quote">ustar interchange format</span>”</span> specified
+ in the POSIX 1003.1-2008 standard).
+ </p></dd><dt><span class="term">String</span></dt><dd><p>
+ The file name for this archive.
+ </p></dd><dt><span class="term">String</span></dt><dd><p>
+ For the main data directory, an empty string. For other
+ tablespaces, the full path to the directory from which this
+ archive was created.
+ </p></dd></dl></div></dd><dt><span class="term">manifest (B)</span></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('m')</span></dt><dd><p>
+ Identifies the message as indicating the start of the backup
+ manifest.
+ </p></dd></dl></div></dd><dt><span class="term">archive or manifest data (B)</span></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('d')</span></dt><dd><p>
+ Identifies the message as containing archive or manifest data.
+ </p></dd><dt><span class="term">Byte<em class="replaceable"><code>n</code></em></span></dt><dd><p>
+ Data bytes.
+ </p></dd></dl></div></dd><dt><span class="term">progress report (B)</span></dt><dd><div class="variablelist"><dl class="variablelist"><dt><span class="term">Byte1('p')</span></dt><dd><p>
+ Identifies the message as a progress report.
+ </p></dd><dt><span class="term">Int64</span></dt><dd><p>
+ The number of bytes from the current tablespace for which
+ processing has been completed.
+ </p></dd></dl></div></dd></dl></div><p>
+ After the CopyOutResponse, or all such responses, have been sent, a
+ final ordinary result set will be sent, containing the WAL end position
+ of the backup, in the same format as the start position.
+ </p><p>
+ The tar archive for the data directory and each tablespace will contain
+ all files in the directories, regardless of whether they are
+ <span class="productname">PostgreSQL</span> files or other files added to the same
+ directory. The only excluded files are:
+
+ </p><div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; "><li class="listitem" style="list-style-type: disc"><p>
+ <code class="filename">postmaster.pid</code>
+ </p></li><li class="listitem" style="list-style-type: disc"><p>
+ <code class="filename">postmaster.opts</code>
+ </p></li><li class="listitem" style="list-style-type: disc"><p>
+ <code class="filename">pg_internal.init</code> (found in multiple directories)
+ </p></li><li class="listitem" style="list-style-type: disc"><p>
+ Various temporary files and directories created during the operation
+ of the PostgreSQL server, such as any file or directory beginning
+ with <code class="filename">pgsql_tmp</code> and temporary relations.
+ </p></li><li class="listitem" style="list-style-type: disc"><p>
+ Unlogged relations, except for the init fork which is required to
+ recreate the (empty) unlogged relation on recovery.
+ </p></li><li class="listitem" style="list-style-type: disc"><p>
+ <code class="filename">pg_wal</code>, including subdirectories. If the backup is run
+ with WAL files included, a synthesized version of <code class="filename">pg_wal</code> will be
+ included, but it will only contain the files necessary for the
+ backup to work, not the rest of the contents.
+ </p></li><li class="listitem" style="list-style-type: disc"><p>
+ <code class="filename">pg_dynshmem</code>, <code class="filename">pg_notify</code>,
+ <code class="filename">pg_replslot</code>, <code class="filename">pg_serial</code>,
+ <code class="filename">pg_snapshots</code>, <code class="filename">pg_stat_tmp</code>, and
+ <code class="filename">pg_subtrans</code> are copied as empty directories (even if
+ they are symbolic links).
+ </p></li><li class="listitem" style="list-style-type: disc"><p>
+ Files other than regular files and directories, such as symbolic
+ links (other than for the directories listed above) and special
+ device files, are skipped. (Symbolic links
+ in <code class="filename">pg_tblspc</code> are maintained.)
+ </p></li></ul></div><p>
+ Owner, group, and file mode are set if the underlying file system on
+ the server supports it.
+ </p></dd></dl></div><p>
+ </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="sasl-authentication.html" title="55.3. SASL Authentication">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="protocol.html" title="Chapter 55. Frontend/Backend Protocol">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="protocol-logical-replication.html" title="55.5. Logical Streaming Replication Protocol">Next</a></td></tr><tr><td width="40%" align="left" valign="top">55.3. SASL Authentication </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.2 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 55.5. Logical Streaming Replication Protocol</td></tr></table></div></body></html> \ No newline at end of file