<command>RELEASE</command>, <command>ROLLBACK TO SAVEPOINT</command>
          </para>
         </listitem>
         <listitem>
          <para>
           <command>EXCEPTION</command> blocks and other internal subtransactions
          </para>
         </listitem>
        </itemizedlist>
      </para>
     </listitem>
     <listitem>
      <para>
       <command>LOCK TABLE</command>, though only when explicitly in one of these modes:
       <literal>ACCESS SHARE</literal>, <literal>ROW SHARE</literal> or <literal>ROW EXCLUSIVE</literal>.
      </para>
     </listitem>
     <listitem>
      <para>
       Plans and resources: <command>PREPARE</command>, <command>EXECUTE</command>,
       <command>DEALLOCATE</command>, <command>DISCARD</command>
      </para>
     </listitem>
     <listitem>
      <para>
       Plugins and extensions: <command>LOAD</command>
      </para>
     </listitem>
     <listitem>
      <para>
       <command>UNLISTEN</command>
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    Transactions started during hot standby will never be assigned a
    transaction ID and cannot write to the system write-ahead log.
    Therefore, the following actions will produce error messages:

    <itemizedlist>
     <listitem>
      <para>
       Data Manipulation Language (DML): <command>INSERT</command>,
       <command>UPDATE</command>, <command>DELETE</command>,
       <command>MERGE</command>, <command>COPY FROM</command>,
       <command>TRUNCATE</command>.
       Note that there are no allowed actions that result in a trigger
       being executed during recovery.  This restriction applies even to
       temporary tables, because table rows cannot be read or written without
       assigning a transaction ID, which is currently not possible in a
       hot standby environment.
      </para>
     </listitem>
     <listitem>
      <para>
       Data Definition Language (DDL): <command>CREATE</command>,
       <command>DROP</command>, <command>ALTER</command>, <command>COMMENT</command>.
       This restriction applies even to temporary tables, because carrying
       out these operations would require updating the system catalog tables.
      </para>
     </listitem>
     <listitem>
      <para>
       <command>SELECT ... FOR SHARE | UPDATE</command>, because row locks cannot be
       taken without updating the underlying data files.
      </para>
     </listitem>
     <listitem>
      <para>
       Rules on <command>SELECT</command> statements that generate DML commands.
      </para>
     </listitem>
     <listitem>
      <para>
       <command>LOCK</command> that explicitly requests a mode higher than <literal>ROW EXCLUSIVE MODE</literal>.
      </para>
     </listitem>
     <listitem>
      <para>
       <command>LOCK</command> in short default form, since it requests <literal>ACCESS EXCLUSIVE MODE</literal>.
      </para>
     </listitem>
     <listitem>
      <para>
       Transaction management commands 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>