Home Explore Blog CI



postgresql

23th chunk of `doc/src/sgml/high-availability.sgml`
7e1bafed9dea1cdd8ac835ff52bca70a146a44a1df724ca40000000100000fa2
 </para>
  </sect1>

 <sect1 id="hot-standby">
  <title>Hot Standby</title>

  <indexterm zone="high-availability">
   <primary>hot standby</primary>
  </indexterm>

   <para>
    Hot standby is the term used to describe the ability to connect to
    the server and run read-only queries while the server is in archive
    recovery or standby mode. This
    is useful both for replication purposes and for restoring a backup
    to a desired state with great precision.
    The term hot standby also refers to the ability of the server to move
    from recovery through to normal operation while users continue running
    queries and/or keep their connections open.
   </para>

   <para>
    Running queries in hot standby mode is similar to normal query operation,
    though there are several usage and administrative differences
    explained below.
   </para>

  <sect2 id="hot-standby-users">
   <title>User's Overview</title>

   <para>
    When the <xref linkend="guc-hot-standby"/> parameter is set to true on a
    standby server, it will begin accepting connections once the recovery has
    brought the system to a consistent state and be ready for hot standby.
    All such connections are
    strictly read-only; not even temporary tables may be written.
   </para>

   <para>
    The data on the standby takes some time to arrive from the primary server
    so there will be a measurable delay between primary and standby. Running the
    same query nearly simultaneously on both primary and standby might therefore
    return differing results. We say that data on the standby is
    <firstterm>eventually consistent</firstterm> with the primary.  Once the
    commit record for a transaction is replayed on the standby, the changes
    made by that transaction will be visible to any new snapshots taken on
    the standby.  Snapshots may be taken at the start of each query or at the
    start of each transaction, depending on the current transaction isolation
    level.  For more details, see <xref linkend="transaction-iso"/>.
   </para>

   <para>
    Transactions started during hot standby may issue the following commands:

    <itemizedlist>
     <listitem>
      <para>
       Query access: <command>SELECT</command>, <command>COPY TO</command>
      </para>
     </listitem>
     <listitem>
      <para>
       Cursor commands: <command>DECLARE</command>, <command>FETCH</command>, <command>CLOSE</command>
      </para>
     </listitem>
     <listitem>
      <para>
       Settings: <command>SHOW</command>, <command>SET</command>, <command>RESET</command>
      </para>
     </listitem>
     <listitem>
      <para>
       Transaction management commands:
        <itemizedlist>
         <listitem>
          <para>
           <command>BEGIN</command>, <command>END</command>, <command>ABORT</command>, <command>START TRANSACTION</command>
          </para>
         </listitem>
         <listitem>
          <para>
           <command>SAVEPOINT</command>, <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>

Title: Hot Standby in PostgreSQL
Summary
This section explains the concept of hot standby in PostgreSQL, which allows users to connect to a standby server and run read-only queries while the server is in archive recovery or standby mode. The standby server accepts connections once recovery has brought the system to a consistent state, and all connections are strictly read-only. The data on the standby server may be slightly delayed compared to the primary server, and is considered eventually consistent. The section also outlines the types of commands that can be issued during hot standby, including query access, cursor commands, settings, transaction management, and lock commands.