doc: Suggesting clearing pg_replslot from a hot filesystem backup.

Maybe we'll settle on another way of solving this problem, but for
now this is the recommended procedure.

Per discussion with Michael Paquier.

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 854b5fde41cf9e7801b46bbda51c9193f18eeb82..06f064e1a6f7db4a01a42482090052187fd95631 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -943,6 +943,21 @@ SELECT pg_stop_backup();
     (These files can confuse <application>pg_ctl</>.)
    </para>
 
+   <para>
+    It is often a good idea to also omit from the backup dump the files
+    within the cluster's <filename>pg_replslot/</> directory, so that
+    replication slots that exist on the master do not become part of the
+    backup.  Otherwise, the subsequent use of the backup to create a standby
+    may result in indefinite retention of WAL files on the standby, and
+    possibly bloat on the master if hot standby feedback is enabled, because
+    the clients that are using those replication slots will still be connecting
+    to and updating the slots on the master, not the standby.  Even if the
+    backup is only intended for use in creating a new master, copying the
+    replication slots isn't expected to be particularly useful, since the
+    contents of those slots will likely be badly out of date by the time
+    the new master comes on line.
+   </para>
+
    <para>
     It's also worth noting that the <function>pg_start_backup</> function
     makes a file named <filename>backup_label</> in the database cluster