From 34aa54b7664c8901cb47bb321439fc33374f4357 Mon Sep 17 00:00:00 2001
From: Ian Barwick <ian@2ndquadrant.com>
Date: Tue, 8 Oct 2019 10:03:44 +0900
Subject: [PATCH] doc: clarify use of --recovery-conf-only

---
 doc/repmgr-standby-clone.xml    | 12 ++++++++++++
 doc/repmgr-standby-register.xml | 23 ++++++++++++++++++-----
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/doc/repmgr-standby-clone.xml b/doc/repmgr-standby-clone.xml
index dcdfe163..98a2091e 100644
--- a/doc/repmgr-standby-clone.xml
+++ b/doc/repmgr-standby-clone.xml
@@ -202,6 +202,18 @@
      ensure the <filename>repmgr.conf</filename>
      file is created for the node, and that it has been registered using
      <command><link linkend="repmgr-standby-register">repmgr standby register</link></command>.
+   </para>
+   <tip>
+     <para>
+       To register a standby which is not running, execute
+       <link linkend="repmgr-standby-register">repmgr standby register --force</link>
+       and provide the connection details for the primary.
+     </para>
+     <para>
+       See <xref linkend="repmgr-standby-register-inactive-node"/> for more details.
+     </para>
+   </tip>
+   <para>
      Then execute the command <command>repmgr standby clone --recovery-conf-only</command>.
      This will create the <filename>recovery.conf</filename> file needed to attach
      the node to its upstream, and will also create a replication slot on the
diff --git a/doc/repmgr-standby-register.xml b/doc/repmgr-standby-register.xml
index 10bb025c..a6df8eff 100644
--- a/doc/repmgr-standby-register.xml
+++ b/doc/repmgr-standby-register.xml
@@ -75,10 +75,22 @@
    <para>
     Under some circumstances you may wish to register a standby which is not
     yet running; this can be the case when using provisioning tools to create
-    a complex replication cluster. In this case, by using the <option>-F/--force</option>
-    option and providing the connection parameters to the primary server,
-    the standby can be registered.
+    a complex replication cluster, or if the node was not cloned by &repmgr;.
    </para>
+   <para>
+    In this case, by using the <option>-F/--force</option>
+    option and providing the connection parameters to the primary server,
+    the standby can be registered even if it has not yet been started.
+   </para>
+   <tip>
+     <para>
+       Connection parameters can either be provided either as a <literal>conninfo</literal> string
+       (e.g. <option>-d 'host=node1 user=repmgr'</option> or as individual connection parameters
+        (<option>-h/--host</option>, <option>-d/--dbname</option>,
+       <option>-U/--user</option>, <option>-p/--port</option> etc.).
+     </para>
+   </tip>
+
    <para>
     Similarly, with cascading replication it may be necessary to register
     a standby whose upstream node has not yet been registered - in this case,
@@ -96,9 +108,10 @@
     <title>Registering a node not cloned by repmgr</title>
     <para>
       If you've cloned a standby using another method (e.g. <application>barman</application>'s
-     <command>barman recover</command> command), first execute
+     <command>barman recover</command> command), register the node as detailed in section
+     <xref linkend="repmgr-standby-register-inactive-node"/> then execute
      <link linkend="repmgr-standby-create-recovery-conf">repmgr standby clone --recovery-conf-only</link>
-     to add the <filename>recovery.conf</filename> file, then register the standby as usual.
+     to generate the appropriate replication configuration.
     </para>
   </refsect1>