that explicitly set non-read-only state:
        <itemizedlist>
         <listitem>
          <para>
            <command>BEGIN READ WRITE</command>,
            <command>START TRANSACTION READ WRITE</command>
          </para>
         </listitem>
         <listitem>
          <para>
            <command>SET TRANSACTION READ WRITE</command>,
            <command>SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE</command>
          </para>
         </listitem>
         <listitem>
          <para>
           <command>SET transaction_read_only = off</command>
          </para>
         </listitem>
        </itemizedlist>
      </para>
     </listitem>
     <listitem>
      <para>
       Two-phase commit commands: <command>PREPARE TRANSACTION</command>,
       <command>COMMIT PREPARED</command>, <command>ROLLBACK PREPARED</command>
       because even read-only transactions need to write WAL in the
       prepare phase (the first phase of two phase commit).
      </para>
     </listitem>
     <listitem>
      <para>
       Sequence updates: <function>nextval()</function>, <function>setval()</function>
      </para>
     </listitem>
     <listitem>
      <para>
       <command>LISTEN</command>, <command>NOTIFY</command>
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    In normal operation, <quote>read-only</quote> transactions are allowed to
    use <command>LISTEN</command> and <command>NOTIFY</command>,
    so hot standby sessions operate under slightly tighter
    restrictions than ordinary read-only sessions.  It is possible that some
    of these restrictions might be loosened in a future release.
   </para>

   <para>
    During hot standby, the parameter <varname>transaction_read_only</varname> is always
    true and may not be changed.  But as long as no attempt is made to modify
    the database, connections during hot standby will act much like any other
    database connection.  If failover or switchover occurs, the database will
    switch to normal processing mode.  Sessions will remain connected while the
    server changes mode.  Once hot standby finishes, it will be possible to
    initiate read-write transactions (even from a session begun during
    hot standby).
   </para>

   <para>
    Users can determine whether hot standby is currently active for their
    session by issuing <command>SHOW in_hot_standby</command>.
    (In server versions before 14, the <varname>in_hot_standby</varname>
    parameter did not exist; a workable substitute method for older servers
    is <command>SHOW transaction_read_only</command>.)  In addition, a set of
    functions (<xref linkend="functions-recovery-info-table"/>) allow users to
    access information about the standby server. These allow you to write
    programs that are aware of the current state of the database. These
    can be used to monitor the progress of recovery, or to allow you to
    write complex programs that restore the database to particular states.
   </para>
  </sect2>

  <sect2 id="hot-standby-conflict">
   <title>Handling Query Conflicts</title>

   <para>
    The primary and standby servers are in many ways loosely connected. Actions
    on the primary will have an effect on the standby. As a result, there is
    potential for negative interactions or conflicts between them. The easiest
    conflict to understand is performance: if a huge data load is taking place
    on the primary then this will generate a similar stream of WAL records on the
    standby, so standby queries may contend for system resources, such as I/O.
   </para>

   <para>
    There are also additional types of conflict that can occur with hot standby.
    These conflicts are <emphasis>hard conflicts</emphasis> in the sense that queries
    might need to be canceled and, in some cases, sessions disconnected to resolve them.
    The user is provided with several ways to handle these
    conflicts. Conflict cases include:

      <itemizedlist>
       <listitem>