diff --git a/doc/appendix-faq.sgml b/doc/appendix-faq.sgml
index cf7256a6..e6320575 100644
--- a/doc/appendix-faq.sgml
+++ b/doc/appendix-faq.sgml
@@ -105,6 +105,7 @@
standby to have been cloned using &repmgr;.
+
Can I use a standby not cloned by &repmgr; as a &repmgr; node?
@@ -118,6 +119,13 @@
+
+ What does &repmgr; write in recovery.conf, and what options can be set there?
+
+ See section Customising recovery.conf.
+
+
+
How can a failed primary be re-added as a standby?
@@ -126,19 +134,23 @@
needs to be re-registered as a standby.
- In PostgreSQL 9.5 and later, it's possible to use pg_rewind
- to re-synchronise the existing data directory, which will usually be much
+ It's possible to use pg_rewind to re-synchronise the existing data
+ directory, which will usually be much
faster than re-cloning the server. However pg_rewind can only
be used if PostgreSQL either has wal_log_hints enabled, or
data checksums were enabled when the cluster was initialized.
- &repmgr; provides the command repmgr node rejoin which can
- optionally execute pg_rewind; see the
- documentation for details.
+ Note that pg_rewind is available as part of the core PostgreSQL
+ distribution from PostgreSQL 9.5, and as a third-party utility for PostgreSQL 9.3 and 9.4.
- If pg_rewind cannot be used, then the data directory will have
+ &repmgr; provides the command repmgr node rejoin which can
+ optionally execute pg_rewind; see the
+ documentation for details, in particular the section .
+
+
+ If pg_rewind cannot be used, then the data directory will need
to be re-cloned from scratch.