<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Streaming Replication Protocol</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.0.22 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Frontend/Backend Protocol"
HREF="protocol.html"><LINK
REL="PREVIOUS"
TITLE="Message Flow"
HREF="protocol-flow.html"><LINK
REL="NEXT"
TITLE="Message Data Types"
HREF="protocol-message-types.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2015-06-13T20:14:15"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.0.22 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Message Flow"
HREF="protocol-flow.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="protocol.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 46. Frontend/Backend Protocol</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Message Data Types"
HREF="protocol-message-types.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PROTOCOL-REPLICATION"
>46.3. Streaming Replication Protocol</A
></H1
><P
>To initiate streaming replication, the frontend sends the
<TT
CLASS="LITERAL"
>replication</TT
> parameter in the startup message. This tells the
backend to go into walsender mode, wherein a small set of replication commands
can be issued instead of SQL statements. Only the simple query protocol can be
used in walsender mode.
The commands accepted in walsender mode are:
<P
></P
></P><DIV
CLASS="VARIABLELIST"
><DL
><DT
>IDENTIFY_SYSTEM</DT
><DD
><P
> Requests the server to identify itself. Server replies with a result
set of a single row, containing two fields:
</P
><P
> <P
></P
></P><DIV
CLASS="VARIABLELIST"
><DL
><DT
>systemid</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
>timeline</DT
><DD
><P
> Current TimelineID. Also useful to check that the standby is
consistent with the master.
</P
></DD
></DL
></DIV
><P>
</P
></DD
><DT
>START_REPLICATION <TT
CLASS="REPLACEABLE"
><I
>XXX</I
></TT
>/<TT
CLASS="REPLACEABLE"
><I
>XXX</I
></TT
></DT
><DD
><P
> Instructs server to start streaming WAL, starting at
WAL position <TT
CLASS="REPLACEABLE"
><I
>XXX</I
></TT
>/<TT
CLASS="REPLACEABLE"
><I
>XXX</I
></TT
>.
The server can reply with an error, e.g. if the requested section of WAL
has already been recycled. On success, server responds with a
CopyOutResponse message, and then starts to stream WAL to the frontend.
WAL will continue to be streamed until the connection is broken;
no further commands will be accepted.
</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 in each CopyData message follows this format:
</P
><P
> <P
></P
></P><DIV
CLASS="VARIABLELIST"
><DL
><DT
>XLogData (B)</DT
><DD
><P
> <P
></P
></P><DIV
CLASS="VARIABLELIST"
><DL
><DT
>Byte1('w')</DT
><DD
><P
> Identifies the message as WAL data.
</P
></DD
><DT
>Byte8</DT
><DD
><P
> The starting point of the WAL data in this message, given in
XLogRecPtr format.
</P
></DD
><DT
>Byte8</DT
><DD
><P
> The current end of WAL on the server, given in
XLogRecPtr format.
</P
></DD
><DT
>Byte8</DT
><DD
><P
> The server's system clock at the time of transmission,
given in TimestampTz format.
</P
></DD
><DT
>Byte<TT
CLASS="REPLACEABLE"
><I
>n</I
></TT
></DT
><DD
><P
> A section of the WAL data stream.
</P
></DD
></DL
></DIV
><P>
</P
></DD
></DL
></DIV
><P>
</P
><P
> A single WAL record is never split across two CopyData 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 CopyData messages.
</P
><P
> Note that all fields within the WAL data and the above-described header
will be in the sending server's native format. Endianness, and the
format for the timestamp, are unpredictable unless the receiver has
verified that the sender's system identifier matches its own
<TT
CLASS="FILENAME"
>pg_control</TT
> contents.
</P
><P
> If the WAL sender process is terminated normally (during postmaster
shutdown), it will send a CommandComplete message before exiting.
This might not happen during an abnormal shutdown, of course.
</P
></DD
></DL
></DIV
><P> </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="protocol-flow.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="protocol-message-types.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Message Flow</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="protocol.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Message Data Types</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
