<para>
    The upshot of all this is that for reasons of both security and
    efficiency, the frontend has no direct way to tell whether a
    cancel request has succeeded.  It must continue to wait for the
    backend to respond to the query.  Issuing a cancel simply improves
    the odds that the current query will finish soon, and improves the
    odds that it will fail with an error message instead of
    succeeding.
   </para>

   <para>
    Since the cancel request is sent across a new connection to the
    server and not across the regular frontend/backend communication
    link, it is possible for the cancel request to be issued by any
    process, not just the frontend whose query is to be canceled.
    This might provide additional flexibility when building
    multiple-process applications.  It also introduces a security
    risk, in that unauthorized persons might try to cancel queries.
    The security risk is addressed by requiring a dynamically
    generated secret key to be supplied in cancel requests.
   </para>
  </sect2>

  <sect2 id="protocol-flow-termination">
   <title>Termination</title>

   <para>
    The normal, graceful termination procedure is that the frontend
    sends a Terminate message and immediately closes the connection.
    On receipt of this message, the backend closes the connection and
    terminates.
   </para>

   <para>
    In rare cases (such as an administrator-commanded database shutdown)
    the backend might disconnect without any frontend request to do so.
    In such cases the backend will attempt to send an error or notice message
    giving the reason for the disconnection before it closes the connection.
   </para>

   <para>
    Other termination scenarios arise from various failure cases, such as core
    dump at one end or the other, loss of the communications link, loss of
    message-boundary synchronization, etc.  If either frontend or backend sees
    an unexpected closure of the connection, it should clean
    up and terminate.  The frontend has the option of launching a new backend
    by recontacting the server if it doesn't want to terminate itself.
    Closing the connection is also advisable if an unrecognizable message type
    is received, since this probably indicates loss of message-boundary sync.
   </para>

   <para>
    For either normal or abnormal termination, any open transaction is
    rolled back, not committed.  One should note however that if a
    frontend disconnects while a non-<command>SELECT</command> query
    is being processed, the backend will probably finish the query
    before noticing the disconnection.  If the query is outside any
    transaction block (<command>BEGIN</command> ... <command>COMMIT</command>
    sequence) then its results might be committed before the
    disconnection is recognized.
   </para>
  </sect2>

  <sect2 id="protocol-flow-ssl">
   <title><acronym>SSL</acronym> Session Encryption</title>

   <para>
    If <productname>PostgreSQL</productname> was built with
    <acronym>SSL</acronym> support, frontend/backend communications
    can be encrypted using <acronym>SSL</acronym>.  This provides
    communication security in environments where attackers might be
    able to capture the session traffic. For more information on
    encrypting <productname>PostgreSQL</productname> sessions with
    <acronym>SSL</acronym>, see <xref linkend="ssl-tcp"/>.
   </para>

   <para>
    To initiate an <acronym>SSL</acronym>-encrypted connection, the
    frontend initially sends an SSLRequest message rather than a
    StartupMessage.  The server then responds with a single byte
    containing <literal>S</literal> or <literal>N</literal>, indicating that it is
    willing or unwilling to perform <acronym>SSL</acronym>,
    respectively.  The frontend might close the connection at this point
    if it is dissatisfied with the response.  To continue after
    <literal>S</literal>, perform an <acronym>SSL</acronym> startup handshake