still uses protocol version 3.0
    by default.
   </para>

   <para>
    A single server can support multiple protocol versions.  The initial
    startup-request message tells the server which protocol version the client
    is attempting to use.  If the major version requested by the client is not
    supported by the server, the connection will be rejected (for example,
    this would occur if the client requested protocol version 4.0, which does
    not exist as of this writing).  If the minor version requested by the
    client is not supported by the server (e.g., the client requests version
    3.2, but the server supports only 3.0), the server may either reject the
    connection or may respond with a NegotiateProtocolVersion message
    containing the highest minor protocol version which it supports.  The
    client may then choose either to continue with the connection using the
    specified protocol version or to abort the connection.
   </para>

   <para>
    The protocol negotiation was introduced in
    <productname>PostgreSQL</productname> version 9.3.21. Earlier versions
    would reject the connection if the client requested a minor version that
    was not supported by the server.
   </para>

   <para>
    <xref linkend="protocol-versions-table"/> shows the currently supported
    protocol versions.
   </para>

   <table id="protocol-versions-table">
    <title>Protocol versions</title>

    <tgroup cols="3">
     <thead>
      <row>
       <entry>Version</entry>
       <entry>Supported by</entry>
       <entry>Description</entry>
      </row>
     </thead>

     <tbody>
      <row>
      <entry>3.2</entry>
      <entry>PostgreSQL 18 and later</entry>
      <entry>Current latest version. The secret key used in query
        cancellation was enlarged from 4 bytes to a variable length field. The
        BackendKeyData message was changed to accommodate that, and the CancelRequest
        message was redefined to have a variable length payload.
      </entry>
      </row>
      <row>
      <entry>3.1</entry>
      <entry>-</entry>
      <entry>Reserved. Version 3.1 has not been used by any PostgreSQL
        version, but it was skipped because old versions of the popular
        pgbouncer application had a bug in the protocol negotiation which made
        it incorrectly claim that it supported version 3.1.
      </entry>
      </row>
      <row>
      <entry>3.0</entry>
      <entry>PostgreSQL 7.4 and later</entry>
      </row>
      <row>
      <entry>2.0</entry>
      <entry>up to PostgreSQL 13</entry>
      <entry>See previous releases of
      the <productname>PostgreSQL</productname> documentation for
      details</entry>
      </row>
     </tbody>
    </tgroup>
   </table>
  </sect2>
 </sect1>

 <sect1 id="protocol-flow">
  <title>Message Flow</title>

  <para>
   This section describes the message flow and the semantics of each
   message type.  (Details of the exact representation of each message
   appear in <xref linkend="protocol-message-formats"/>.)  There are
   several different sub-protocols depending on the state of the
   connection: start-up, query, function call,
   <command>COPY</command>, and termination.  There are also special
   provisions for asynchronous operations (including notification
   responses and command cancellation), which can occur at any time
   after the start-up phase.
  </para>

  <sect2 id="protocol-flow-start-up">
   <title>Start-up</title>

   <para>
    To begin a session, a frontend opens a connection to the server and sends
    a startup message.  This message includes the names of the user and of the
    database the user wants to connect to; it also identifies the particular
    protocol version to be used.  (Optionally, the startup message can include
    additional settings for run-time parameters.)
    The server then uses this information and
    the contents of its configuration files (such as
    <filename>pg_hba.conf</filename>) to determine
    whether