protocol version (NegotiateProtocolVersion), but in the normal case
    the backend will send some ParameterStatus messages, BackendKeyData, and
    finally ReadyForQuery.
   </para>

   <para>
    During this phase the backend will attempt to apply any additional
    run-time parameter settings that were given in the startup message.
    If successful, these values become session defaults.  An error causes
    ErrorResponse and exit.
   </para>

   <para>
    The possible messages from the backend in this phase are:

    <variablelist>
     <varlistentry>
      <term>BackendKeyData</term>
      <listitem>
       <para>
        This message provides secret-key data that the frontend must
        save if it wants to be able to issue cancel requests later.
        The frontend should not respond to this message, but should
        continue listening for a ReadyForQuery message.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ParameterStatus</term>
      <listitem>
       <para>
        This message informs the frontend about the current (initial)
         setting of backend parameters, such as <xref
         linkend="guc-client-encoding"/> or <xref linkend="guc-datestyle"/>.
         The frontend can ignore this message, or record the settings
         for its future use; see <xref linkend="protocol-async"/> for
         more details.  The frontend should not respond to this
         message, but should continue listening for a ReadyForQuery
         message.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ReadyForQuery</term>
      <listitem>
       <para>
        Start-up is completed.  The frontend can now issue commands.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ErrorResponse</term>
      <listitem>
       <para>
        Start-up failed.  The connection is closed after sending this
        message.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>NoticeResponse</term>
      <listitem>
       <para>
        A warning message has been issued.  The frontend should
        display the message but continue listening for ReadyForQuery
        or ErrorResponse.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>

   <para>
    The ReadyForQuery message is the same one that the backend will
    issue after each command cycle.  Depending on the coding needs of
    the frontend, it is reasonable to consider ReadyForQuery as
    starting a command cycle, or to consider ReadyForQuery as ending the
    start-up phase and each subsequent command cycle.
   </para>
  </sect2>

  <sect2 id="protocol-flow-simple-query">
   <title>Simple Query</title>

   <para>
    A simple query cycle is initiated by the frontend sending a Query message
    to the backend.  The message includes an SQL command (or commands)
    expressed as a text string.
    The backend then sends one or more response
    messages depending on the contents of the query command string,
    and finally a ReadyForQuery response message.  ReadyForQuery
    informs the frontend that it can safely send a new command.
    (It is not actually necessary for the frontend to wait for
    ReadyForQuery before issuing another command, but the frontend must
    then take responsibility for figuring out what happens if the earlier
    command fails and already-issued later commands succeed.)
   </para>

   <para>
    The possible response messages from the backend are:

    <variablelist>
     <varlistentry>
      <term>CommandComplete</term>
      <listitem>
       <para>
        An SQL command completed normally.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>CopyInResponse</term>
      <listitem>
       <para>
        The backend is ready to copy data from the frontend to a
        table; see <xref linkend="protocol-copy"/>.
       </para>
      </listitem>