Documentation: update markup

doc/appendix-faq.sgml

@@ -15,7 +15,7 @@
      <para>
       &repmgr; 3.x builds on the improved replication facilities added
       in PostgreSQL 9.3, as well as improved automated failover support
-      via <command>repmgrd</command>, and is not compatible with PostgreSQL 9.2
+      via <application>repmgrd</application>, and is not compatible with PostgreSQL 9.2
       and earlier. We recommend upgrading to &repmgr; 4, as the &repmgr; 3.x
       series will no longer be actively maintained.
      </para>
@@ -126,19 +126,19 @@
 
   <sect2 id="faq-repmgr-shared-preload-libaries-no-repmgrd" xreflabel="shared_preload_libraries without repmgrd">
     <title>Do I need to include <literal>shared_preload_libraries = 'repmgr'</literal>
-      in <filename>postgresql.conf</filename> if I'm not using <command>repmgrd</command>?</title>
+      in <filename>postgresql.conf</filename> if I'm not using <application>repmgrd</application>?</title>
    <para>
-    No, the <literal>repmgr</literal> shared library is only needed when running <command>repmgrd</command>.
+    No, the <literal>repmgr</literal> shared library is only needed when running <application>repmgrd</application>.
-    If you later decide to run <command>repmgrd</command>, you just need to add
+    If you later decide to run <application>repmgrd</application>, you just need to add
     <literal>shared_preload_libraries = 'repmgr'</literal> and restart PostgreSQL.
    </para>
   </sect2>
 
   <sect2 id="faq-repmgr-permissions" xreflabel="Replication permission problems">
    <title>I've provided replication permission for the <literal>repmgr</literal> user in <filename>pg_hba.conf</filename>
-     but <command>repmgr</command>/<command>repmgrd</command> complains it can't connect to the server... Why?</title>
+     but <command>repmgr</command>/<application>repmgrd</application> complains it can't connect to the server... Why?</title>
    <para>
-    <command>repmgr</command> and<command>repmgrd</command> need to be able to connect to the repmgr database
+    <command>repmgr</command> and<application>repmgrd</application> need to be able to connect to the repmgr database
     with a normal connection to query metadata. The <literal>replication</literal> connection
     permission is for PostgreSQL's streaming replication (and doesn't  necessarily need to be the <literal>repmgr</literal> user).
    </para>
@@ -170,7 +170,7 @@
  </sect1>
 
  <sect1 id="faq-repmgrd" xreflabel="repmgrd">
-  <title><command>repmgrd</command></title>
+  <title><application>repmgrd</application></title>
 
 
   <sect2 id="faq-repmgrd-prevent-promotion" xreflabel="Prevent standby from being promoted to primary">
@@ -186,12 +186,12 @@
   </sect2>
 
   <sect2 id="faq-repmgrd-delayed-standby" xreflabel="Delayed standby support">
-   <title>Does <command>repmgrd</command> support delayed standbys?</title>
+   <title>Does <application>repmgrd</application> support delayed standbys?</title>
    <para>
-    <command>repmgrd</command> can monitor delayed standbys - those set up with
+    <application>repmgrd</application> can monitor delayed standbys - those set up with
     <varname>recovery_min_apply_delay</varname> set to a non-zero value
     in <filename>recovery.conf</filename> - but as it's not currently possible
-    to directly examine the value applied to the standby, <command>repmgrd</command>
+    to directly examine the value applied to the standby, <application>repmgrd</application>
     may not be able to properly evaluate the node as a promotion candidate.
    </para>
    <para>
@@ -200,13 +200,13 @@
     <filename>repmgr.conf</filename>.
    </para>
    <para>
-    Note that after registering a delayed standby, <command>repmgrd</command> will only start
+    Note that after registering a delayed standby, <application>repmgrd</application> will only start
     once the metadata added in the master node has been replicated.
    </para>
   </sect2>
 
   <sect2 id="faq-repmgrd-logfile-rotate" xreflabel="repmgrd logfile rotation">
-   <title>How can I get <command>repmgrd</command> to rotate its logfile?</title>
+   <title>How can I get <application>repmgrd</application> to rotate its logfile?</title>
    <para>
      Configure your system's <literal>logrotate</literal> service to do this; see <xref linkend="repmgrd-log-rotation">.
    </para>
@@ -214,11 +214,11 @@
   </sect2>
 
   <sect2 id="faq-repmgrd-recloned-no-start" xreflabel="repmgrd not restarting after node cloned">
-   <title>I've recloned a failed master as a standby, but <command>repmgrd</command> refuses to start?</title>
+   <title>I've recloned a failed master as a standby, but <application>repmgrd</application> refuses to start?</title>
    <para>
     Check you registered the standby after recloning. If unregistered, the standby
     cannot be considered as a promotion candidate even if <varname>failover</varname> is set to
-    <literal>automatic</literal>, which is probably not what you want. <command>repmgrd</command> will start if
+    <literal>automatic</literal>, which is probably not what you want. <application>repmgrd</application> will start if
     <varname>failover</varname> is set to <literal>manual</literal> so the node's replication status can still
   be monitored, if desired.
    </para>

doc/event-notifications.sgml

@@ -1,7 +1,7 @@
 <chapter id="event-notifications" xreflabel="event notifications">
  <title>Event Notifications</title>
  <para>
-  Each time &repmgr; or <command>repmgrd</command> perform a significant event, a record
+  Each time &repmgr; or <application>repmgrd</application> perform a significant event, a record
   of that event is written into the <literal>repmgr.events</literal> table together with
   a timestamp, an indication of failure or success, and further details
   if appropriate. This is useful for gaining an overview of events

doc/install-requirements.sgml

@@ -31,7 +31,7 @@
 
   <para>
    A dedicated system user for &repmgr; is *not* required; as many &repmgr; and
-   <command>repmgrd</command> actions require direct access to the PostgreSQL data directory,
+   <application>repmgrd</application> actions require direct access to the PostgreSQL data directory,
    these commands should be executed by the <literal>postgres</literal> user.
   </para>
 

doc/overview.sgml

@@ -57,7 +57,7 @@
      <listitem>
       <simpara>
        This is the action which occurs if a primary server fails and a suitable standby
-       is  promoted as the new primary. The <command>repmgrd</command> daemon supports automatic failover
+       is  promoted as the new primary. The <application>repmgrd</application> daemon supports automatic failover
        to minimise downtime.
       </simpara>
      </listitem>
@@ -173,7 +173,7 @@
         </listitem>
         <listitem>
           <simpara><literal>repmgr.monitoring_history</literal>: historical standby monitoring information
-            written by <command>repmgrd</command></simpara>
+            written by <application>repmgrd</application></simpara>
         </listitem>
        </itemizedlist>
       </para>
@@ -189,7 +189,7 @@
            name of the server's upstream node</simpara>
         </listitem>
         <listitem>
-          <simpara>repmgr.replication_status: when <command>repmgrd</command>'s monitoring is enabled, shows
+          <simpara>repmgr.replication_status: when <application>repmgrd</application>'s monitoring is enabled, shows
             current monitoring status for each standby.</simpara>
         </listitem>
        </itemizedlist>

doc/quickstart.sgml

@@ -286,7 +286,7 @@
     slot_name        |
     config_file      | /etc/repmgr.conf</programlisting>
   <para>
-    Each server in the replication cluster will have its own record. If <command>repmgrd</command>
+    Each server in the replication cluster will have its own record. If <application>repmgrd</application>
     is in use, the fields <literal>upstream_node_id</literal>, <literal>active</literal> and
     <literal>type</literal> will be updated when the node's status or role changes.
   </para>

doc/repmgr-cluster-cleanup.sgml

@@ -15,7 +15,7 @@
   </para>
   <note>
    <simpara>
-    Monitoring history will only be written if <command>repmgrd</command> is active, and
+    Monitoring history will only be written if <application>repmgrd</application> is active, and
     <varname>monitoring_history</varname> is set to <literal>true</literal> in
     <filename>repmgr.conf</filename>.
    </simpara>

doc/repmgr-standby-promote.sgml

@@ -12,7 +12,7 @@
   <para>
    If the standby promotion succeeds, the server will not need to be
    restarted. However any other standbys will need to follow the new server,
-   by using <xref linkend="repmgr-standby-follow">; if <command>repmgrd</command>
+   by using <xref linkend="repmgr-standby-follow">; if <application>repmgrd</application>
    is active, it will handle this automatically.
   </para>
 </chapter>

doc/repmgr-standby-register.sgml

@@ -4,7 +4,7 @@
   <para>
    <command>repmgr standby register</command> adds a standby's information to
    the &repmgr; metadata. This command needs to be executed to enable
-   promote/follow operations and to allow <command>repmgrd</command> to work with the node.
+   promote/follow operations and to allow <application>repmgrd</application> to work with the node.
    An existing standby can be registered using this command. Execute with the
    <literal>--dry-run</literal> option to check what would happen without actually registering the
    standby.
@@ -15,7 +15,7 @@
    <para>
      Depending on your environment and workload, it may take some time for
      the standby's node record to propagate from the primary to the standby. Some
-     actions (such as starting <command>repmgrd</command>) require that the standby's node record
+     actions (such as starting <application>repmgrd</application>) require that the standby's node record
      is present and up-to-date to function correctly.
    </para>
    <para>

doc/repmgr-standby-switchover.sgml

@@ -18,7 +18,7 @@
     possible without actually changing the status of either node.
   </para>
   <para>
-    <command>repmgrd</command> should not be active on any nodes while a switchover is being
+    <application>repmgrd</application> should not be active on any nodes while a switchover is being
     executed. This restriction may be lifted in a later version.
   </para>
   <para>

doc/repmgrd-automatic-failover.sgml

@@ -2,7 +2,7 @@
  <title>Automatic failover with repmgrd</title>
 
  <para>
-  <command>repmgrd</command> is a management and monitoring daemon which runs
+  <application>repmgrd</application> is a management and monitoring daemon which runs
   on each node in a replication cluster. It can automate actions such as
   failover and updating standbys to follow the new primary, as well as
   providing monitoring information about the state of each standby.

doc/repmgrd-cascading-replication.sgml

@@ -3,7 +3,7 @@
  <para>
   Cascading replication - where a standby can connect to an upstream node and not
   the primary server itself - was introduced in PostgreSQL 9.2. &repmgr; and
-  <command>repmgrd</command> support cascading replication by keeping track of the relationship
+  <application>repmgrd</application> support cascading replication by keeping track of the relationship
   between standby servers - each node record is stored with the node id of its
   upstream ("parent") server (except of course the primary server).
  </para>

doc/repmgrd-configuration.sgml

@@ -1,7 +1,7 @@
 <chapter id="repmgrd-configuration">
  <title>repmgrd configuration</title>
  <para>
-  To use <command>repmgrd</command>, its associated function library must be
+  To use <application>repmgrd</application>, its associated function library must be
   included in <filename>postgresql.conf</filename> with:
 
   <programlisting>
@@ -12,7 +12,7 @@
   the <ulink url="https://www.postgresql.org/docs/current/static/runtime-config-client.html#GUC-SHARED-PRELOAD-LIBRARIES">PostgreSQL documentation</ulink>.
  </para>
  <para>
-  Additionally the following <command>repmgrd</command> options *must* be set in
+  Additionally the following <application>repmgrd</application> options *must* be set in
   <filename>repmgr.conf</filename> (adjust configuration file locations as appropriate):
   <programlisting>
     failover=automatic
@@ -21,13 +21,13 @@
  </para>
  <para>
   Note that the <literal>--log-to-file</literal> option will cause
-  output generated by the &repmgr; command, when executed by <command>repmgrd</command>,
+  output generated by the &repmgr; command, when executed by <application>repmgrd</application>,
-  to be logged to the same destination configured to receive log output for <command>repmgrd</command>.
+  to be logged to the same destination configured to receive log output for <application>repmgrd</application>.
-  See <filename>repmgr.conf.sample</filename> for further <command>repmgrd</command>-specific settings.
+  See <filename>repmgr.conf.sample</filename> for further <application>repmgrd</application>-specific settings.
  </para>
  <para>
   When <varname>failover</varname> is set to <literal>automatic</literal>, upon detecting failure
-  of the current  primary, <command>repmgrd</command> will execute one of
+  of the current  primary, <application>repmgrd</application> will execute one of
   <varname>promote_command</varname> or <varname>follow_command</varname>,
   depending on whether the current server is to become the new primary, or
   needs to follow another server which has become the new primary. Note that
@@ -41,7 +41,7 @@
  <para>
   The <varname>follow_command</varname> should provide the <literal>--upstream-node-id=%n</literal>
   option to <command>repmgr standby follow</command>; the <literal>%n</literal> will be replaced by
-  <command>repmgrd</command> with the ID of the new primary node. If this is not provided, &repmgr;
+  <application>repmgrd</application> with the ID of the new primary node. If this is not provided, &repmgr;
   will attempt to determine the new primary by itself, but  if the
   original primary comes back online after the new primary is promoted, there is a risk that
   <command>repmgr standby follow</command> will result in the node continuing to follow
@@ -73,7 +73,7 @@
  <sect1 id="repmgrd-log-rotation">
   <title>repmgrd log rotation</title>
   <para>
-   To ensure the current <command>repmgrd</command> logfile does not grow
+   To ensure the current <application>repmgrd</application> logfile does not grow
    indefinitely, configure your system's <command>logrotate</command> to
    regularly rotate it.
   </para>

doc/repmgrd-degraded-monitoring.sgml

@@ -1,9 +1,9 @@
 <chapter id="repmgrd-degraded-monitoring">
  <title>"degraded monitoring" mode</title>
  <para>
-  In certain circumstances, <command>repmgrd</command> is not able to fulfill its primary mission
+  In certain circumstances, <application>repmgrd</application> is not able to fulfill its primary mission
   of monitoring the nodes' upstream server. In these cases it enters "degraded
-  monitoring" mode, where <command>repmgrd</command> remains active but is waiting for the situation
+  monitoring" mode, where <application>repmgrd</application> remains active but is waiting for the situation
   to be resolved.
  </para>
  <para>
@@ -63,7 +63,7 @@
  <para>
   By default, <literal>repmgrd</literal> will continue in degraded monitoring mode indefinitely.
   However a timeout (in seconds) can be set with <varname>degraded_monitoring_timeout</varname>,
-  after which <command>repmgrd</command> will terminate.
+  after which <application>repmgrd</application> will terminate.
 
  </para>
 

doc/repmgrd-demonstration.sgml

@@ -13,7 +13,7 @@
      3  | node3 | standby |   running | node1    | default  | host=node3 dbname=repmgr user=repmgr</programlisting>
  </para>
  <para>
-  Start <command>repmgrd</command> on each standby and verify that it's running by examining the
+  Start <application>repmgrd</application> on each standby and verify that it's running by examining the
   log output, which at log level <literal>INFO</literal> will look like this:
   <programlisting>
     [2017-08-24 17:31:00] [NOTICE] using configuration file "/etc/repmgr.conf"
@@ -22,7 +22,7 @@
     [2017-08-24 17:31:00] [INFO] monitoring connection to upstream node "node1" (node ID: 1)</programlisting>
  </para>
  <para>
-  Each <command>repmgrd</command> should also have recorded its successful startup as an event:
+  Each <application>repmgrd</application> should also have recorded its successful startup as an event:
   <programlisting>
     $ repmgr -f /etc/repmgr.conf cluster event --event=repmgrd_start
      Node ID | Name  | Event         | OK | Timestamp           | Details
@@ -38,8 +38,8 @@
  </para>
  <para>
   This will force the primary to shut down straight away, aborting all processes
-  and transactions.  This will cause a flurry of activity in the <command>repmgrd</command> log
+  and transactions.  This will cause a flurry of activity in the <application>repmgrd</application> log
-  files as each <command>repmgrd</command> detects the failure of the primary and a failover
+  files as each <application>repmgrd</application> detects the failure of the primary and a failover
   decision is made. This is an extract from the log of a standby server (<literal>node2</literal>)
   which has promoted to new primary after failure of the original primary (<literal>node1</literal>).
   <programlisting>

doc/repmgrd-monitoring.sgml

@@ -39,7 +39,7 @@
   specify how many day's worth of data should be retained.
  </para>
  <para>
-  It's possible to use <command>repmgrd</command> to run in monitoring
+  It's possible to use <application>repmgrd</application> to run in monitoring
   mode only (without automatic failover capability) for some or all
   nodes by setting <literal>failover=manual</literal> in the node's
   <filename>repmgr.conf</filename> file. In the event of the node's upstream failing,

doc/repmgrd-network-split.sgml

@@ -32,8 +32,8 @@
     location='dc1'</programlisting>
  </para>
  <para>
-  In a failover situation, <command>repmgrd</command> will check if any servers in the
+  In a failover situation, <application>repmgrd</application> will check if any servers in the
-  same location as the current primary node are visible.  If not, <command>repmgrd</command>
+  same location as the current primary node are visible.  If not, <application>repmgrd</application>
   will assume a network interruption and not promote any node in any
   other location (it will however enter <xref linkend="repmgrd-degraded-monitoring"> mode until
   a primary becomes visible).

doc/switchover.sgml

@@ -90,7 +90,7 @@
     manually with <command>repmgr node check --archive-ready</command>.
    </para>
    <para>
-    Ensure that <command>repmgrd</command> is *not* running anywhere to prevent it unintentionally
+    Ensure that <application>repmgrd</application> is *not* running anywhere to prevent it unintentionally
     promoting a node.
    </para>
    <para>
@@ -195,9 +195,9 @@
     </listitem>
     <listitem>
      <simpara>
-      <command>repmgrd</command> should not be running with setting <varname>failover=automatic</varname>
+      <application>repmgrd</application> should not be running with setting <varname>failover=automatic</varname>
       in <filename>repmgr.conf</filename> when a switchover is carried out, otherwise the
-      <command>repmgrd</command> daemon may try and promote a standby by itself.
+      <application>repmgrd</application> daemon may try and promote a standby by itself.
      </simpara>
     </listitem>
    </itemizedlist>

doc/upgrading-repmgr.sgml

@@ -18,9 +18,9 @@
   <command>ALTER EXTENSION repmgr UPDATE</command>.
  </para>
  <para>
-  If <command>repmgrd</command> is running, it may be necessary to restart
+  If <application>repmgrd</application> is running, it may be necessary to restart
   the PostgreSQL server if the upgrade contains changes to the shared object
-  file used by <command>repmgrd</command>; check the release notes for details.
+  file used by <application>repmgrd</application>; check the release notes for details.
  </para>
 
  <sect1 id="upgrading-from-repmgr-3" xreflabel="Upgrading from repmgr 3.x">
@@ -83,7 +83,7 @@
       </listitem>
       <listitem>
         <simpara><varname>monitoring_history</varname>: this replaces the
-          <command>repmgrd</command> command line option
+          <application>repmgrd</application> command line option
           <literal>--monitoring-history</literal></simpara>
       </listitem>
      </itemizedlist>
@@ -169,7 +169,7 @@
   <sect2>
    <title>Upgrading the repmgr schema</title>
    <para>
-    Ensure <command>repmgrd</command> is not running, or any cron jobs which execute the
+    Ensure <application>repmgrd</application> is not running, or any cron jobs which execute the
     <command>repmgr</command> binary.
    </para>
    <para>
@@ -235,7 +235,7 @@
     </para>
     <para>
      Check the data is updated as expected by examining the <structname>repmgr.nodes</structname>
-     table; restart <command>repmgrd</command> if required.
+     table; restart <application>repmgrd</application> if required.
     </para>
     <para>
      The original <literal>repmgr_$cluster</literal> schema can be dropped at any time.