use the same format, but the message design does not
    assume this.)
   </para>

  </sect2>

  <sect2 id="protocol-async">
   <title>Asynchronous Operations</title>

   <para>
    There are several cases in which the backend will send messages that
    are not specifically prompted by the frontend's command stream.
    Frontends must be prepared to deal with these messages at any time,
    even when not engaged in a query.
    At minimum, one should check for these cases before beginning to
    read a query response.
   </para>

   <para>
    It is possible for NoticeResponse messages to be generated due to
    outside activity; for example, if the database administrator commands
    a <quote>fast</quote> database shutdown, the backend will send a NoticeResponse
    indicating this fact before closing the connection.  Accordingly,
    frontends should always be prepared to accept and display NoticeResponse
    messages, even when the connection is nominally idle.
   </para>

   <para>
    ParameterStatus messages will be generated whenever the active
    value changes for any of the parameters the backend believes the
    frontend should know about.  Most commonly this occurs in response
    to a <command>SET</command> SQL command executed by the frontend, and
    this case is effectively synchronous &mdash; but it is also possible
    for parameter status changes to occur because the administrator
    changed a configuration file and then sent the
    <systemitem>SIGHUP</systemitem> signal to the server.  Also,
    if a <command>SET</command> command is rolled back, an appropriate
    ParameterStatus message will be generated to report the current
    effective value.
   </para>

   <para>
    At present there is a hard-wired set of parameters for which
    ParameterStatus will be generated.  They are:
    <simplelist type="vert" columns="2">
     <member><varname>application_name</varname></member>
     <member><varname>client_encoding</varname></member>
     <member><varname>DateStyle</varname></member>
     <member><varname>default_transaction_read_only</varname></member>
     <member><varname>in_hot_standby</varname></member>
     <member><varname>integer_datetimes</varname></member>
     <member><varname>IntervalStyle</varname></member>
     <member><varname>is_superuser</varname></member>
     <member><varname>scram_iterations</varname></member>
     <member><varname>search_path</varname></member>
     <member><varname>server_encoding</varname></member>
     <member><varname>server_version</varname></member>
     <member><varname>session_authorization</varname></member>
     <member><varname>standard_conforming_strings</varname></member>
     <member><varname>TimeZone</varname></member>
    </simplelist>
    (<varname>default_transaction_read_only</varname> and
    <varname>in_hot_standby</varname> were not reported by releases before
    14; <varname>scram_iterations</varname> was not reported by releases
    before 16; <varname>search_path</varname> was not reported by releases
    before 18.)
    Note that
    <varname>server_version</varname>,
    <varname>server_encoding</varname> and
    <varname>integer_datetimes</varname>
    are pseudo-parameters that cannot change after startup.
    This set might change in the future, or even become configurable.
    Accordingly, a frontend should simply ignore ParameterStatus for
    parameters that it does not understand or care about.
   </para>

   <para>
    If a frontend issues a <command>LISTEN</command> command, then the
    backend will send a NotificationResponse message (not to be
    confused with NoticeResponse!)  whenever a
    <command>NOTIFY</command> command is executed for the same
    channel name.
   </para>

   <note>
    <para>
     At present, NotificationResponse can only be sent outside a
     transaction, and thus it will not occur in the middle of a
     command-response series, though it might occur just before ReadyForQuery.
     It is unwise to