doc: Standardize capitalization of term "hot standby"/"Hot Standby"

"Hot Standby" was capitalized in a couple of places in the docs, as the
style primarily used when it was introduced, but this has not been much
respected across the years.  Per discussion, it is more natural for the
reader to use "hot standby" (aka lower-case only) when in the middle of
a sentence, and "Hot standby" (aka capitalized) in a title.  This commit
adjusts all the places in the docs to be consistent with this choice,
rather than applying one style or the other midway.

Author: Daniel Westermann
Reviewed-by: Kyotaro Horiguchi, Aleksander Alekseev, Robert Treat
Discussion: https://postgr.es/m/GVAP278MB093160025A779A1A5788D0EAD2039@GVAP278MB0931.CHEP278.PROD.OUTLOOK.COM

doc/src/sgml/amcheck.sgml

@@ -174,7 +174,7 @@ ORDER BY c.relpages DESC LIMIT 10;
       hypothetically, undiscovered bugs in the underlying B-Tree index
       access method code.  Note that
       <function>bt_index_parent_check</function> cannot be used when
-      Hot Standby mode is enabled (i.e., on read-only physical
+      hot standby mode is enabled (i.e., on read-only physical
       replicas), unlike <function>bt_index_check</function>.
      </para>
     </listitem>

doc/src/sgml/config.sgml

@@ -4553,7 +4553,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
       </term>
       <listitem>
        <para>
-        When Hot Standby is active, this parameter determines how long the
+        When hot standby is active, this parameter determines how long the
         standby server should wait before canceling standby queries that
         conflict with about-to-be-applied WAL entries, as described in
         <xref linkend="hot-standby-conflict"/>.
@@ -4585,7 +4585,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
       </term>
       <listitem>
        <para>
-        When Hot Standby is active, this parameter determines how long the
+        When hot standby is active, this parameter determines how long the
         standby server should wait before canceling standby queries that
         conflict with about-to-be-applied WAL entries, as described in
         <xref linkend="hot-standby-conflict"/>.
@@ -10890,7 +10890,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
         Enables logging of recovery-related debugging output that otherwise
         would not be logged. This parameter allows the user to override the
         normal setting of <xref linkend="guc-log-min-messages"/>, but only for
-        specific messages. This is intended for use in debugging Hot Standby.
+        specific messages. This is intended for use in debugging hot standby.
         Valid values are <literal>DEBUG5</literal>, <literal>DEBUG4</literal>,
         <literal>DEBUG3</literal>, <literal>DEBUG2</literal>, <literal>DEBUG1</literal>, and
         <literal>LOG</literal>.  The default, <literal>LOG</literal>, does not affect

doc/src/sgml/high-availability.sgml

@@ -548,8 +548,8 @@ protocol to make nodes agree on a serializable transactional order.
    rollforward will take considerably longer, so that technique only
    offers a solution for disaster recovery, not high availability.
    A standby server can also be used for read-only queries, in which case
-   it is called a Hot Standby server. See <xref linkend="hot-standby"/> for
-   more information.
+   it is called a <firstterm>hot standby</firstterm> server. See 
+   <xref linkend="hot-standby"/> for more information.
   </para>
 
   <indexterm zone="high-availability">
@@ -1032,7 +1032,7 @@ primary_slot_name = 'node_a_slot'
    </para>
 
    <para>
-    Hot Standby feedback propagates upstream, whatever the cascaded arrangement.
+    Hot standby feedback propagates upstream, whatever the cascaded arrangement.
    </para>
 
    <para>
@@ -1499,16 +1499,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
   <title>Hot Standby</title>
 
   <indexterm zone="high-availability">
-   <primary>Hot Standby</primary>
+   <primary>hot standby</primary>
   </indexterm>
 
    <para>
-    Hot Standby is the term used to describe the ability to connect to
+    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
+    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>
@@ -1623,7 +1623,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
        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.
+       hot standby environment.
       </para>
      </listitem>
      <listitem>
@@ -1703,7 +1703,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
    <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
+    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>
@@ -1746,7 +1746,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
    </para>
 
    <para>
-    There are also additional types of conflict that can occur with Hot Standby.
+    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
@@ -1947,8 +1947,8 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
     If <varname>hot_standby</varname> is <literal>on</literal> in <filename>postgresql.conf</filename>
     (the default value) and there is a
     <link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary><secondary>for hot standby</secondary></indexterm>
-    file present, the server will run in Hot Standby mode.
-    However, it may take some time for Hot Standby connections to be allowed,
+    file present, the server will run in hot standby mode.
+    However, it may take some time for hot standby connections to be allowed,
     because the server will not accept connections until it has completed
     sufficient recovery to provide a consistent state against which queries
     can run.  During this period,
@@ -2282,7 +2282,7 @@ HINT:  You can then restart the server after making the necessary configuration
    <title>Caveats</title>
 
    <para>
-    There are several limitations of Hot Standby.
+    There are several limitations of hot standby.
     These can and probably will be fixed in future releases:
 
   <itemizedlist>
@@ -2299,7 +2299,7 @@ HINT:  You can then restart the server after making the necessary configuration
     <para>
      Valid starting points for standby queries are generated at each
      checkpoint on the primary. If the standby is shut down while the primary
-     is in a shutdown state, it might not be possible to re-enter Hot Standby
+     is in a shutdown state, it might not be possible to re-enter hot standby
      until the primary is started up, so that it generates further starting
      points in the WAL logs.  This situation isn't a problem in the most
      common situations where it might happen. Generally, if the primary is

doc/src/sgml/mvcc.sgml

@@ -1741,7 +1741,7 @@ SELECT pg_advisory_lock(q.id) FROM
 
    <para>
     Support for the Serializable transaction isolation level has not yet
-    been added to Hot Standby replication targets (described in
+    been added to hot standby replication targets (described in
     <xref linkend="hot-standby"/>).  The strictest isolation level currently
     supported in hot standby mode is Repeatable Read.  While performing all
     permanent database writes within Serializable transactions on the

doc/src/sgml/protocol.sgml

@@ -2417,7 +2417,7 @@ The commands accepted in replication mode are:
       <variablelist>
       <varlistentry id="protocol-replication-hot-standby-feedback-message">
       <term>
-          Hot Standby feedback message (F)
+          Hot standby feedback message (F)
       </term>
       <listitem>
       <para>
@@ -2428,7 +2428,7 @@ The commands accepted in replication mode are:
       </term>
       <listitem>
       <para>
-          Identifies the message as a Hot Standby feedback message.
+          Identifies the message as a hot standby feedback message.
       </para>
       </listitem>
       </varlistentry>
@@ -2451,7 +2451,7 @@ The commands accepted in replication mode are:
       <para>
           The standby's current global xmin, excluding the catalog_xmin from any
           replication slots. If both this value and the following
-          catalog_xmin are 0 this is treated as a notification that Hot Standby
+          catalog_xmin are 0 this is treated as a notification that hot standby
           feedback will no longer be sent on this connection. Later non-zero
           messages may reinitiate the feedback mechanism.
       </para>