so that the server knows which WAL segments,
       and if <varname>hot_standby_feedback</varname> is on which transactions,
       are still needed by the standby.
      </para>

      <para>
       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.
      </para>

      <para>
       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 <type>int8</type>), and the
       second column is the WAL location where the switch happened (type <type>text</type>). 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 <literal>START_REPLICATION</literal> itself), and
       is ready to accept a new command.
      </para>

      <para>
       WAL data is sent as a series of CopyData messages;
       see <xref linkend="protocol-message-types"/> and <xref
       linkend="protocol-message-formats"/> for details.
       (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:
      </para>

      <variablelist>
       <varlistentry id="protocol-replication-xlogdata">
        <term>XLogData (B)</term>
        <listitem>
         <variablelist>
          <varlistentry>
           <term>Byte1('w')</term>
           <listitem>
            <para>
             Identifies the message as WAL data.
            </para>
           </listitem>
          </varlistentry>

          <varlistentry>
           <term>Int64</term>
           <listitem>
            <para>
             The starting point of the WAL data in this message.
            </para>
           </listitem>
          </varlistentry>

          <varlistentry>
           <term>Int64</term>
           <listitem>
            <para>
             The current end of WAL on the server.
            </para>
           </listitem>
          </varlistentry>

          <varlistentry>
           <term>Int64</term>
           <listitem>
            <para>
             The server's system clock at the time of transmission, as
             microseconds since midnight on 2000-01-01.
            </para>
           </listitem>
          </varlistentry>

          <varlistentry>
           <term>Byte<replaceable>n</replaceable></term>
           <listitem>
            <para>
             A section of the WAL data stream.
            </para>

            <para>
             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.
            </para>
           </listitem>
          </varlistentry>
         </variablelist>
        </listitem>
       </varlistentry>

       <varlistentry id="protocol-replication-primary-keepalive-message">