From: Robert Haas <rhaas@postgresql.org>
Date: Mon, 14 Apr 2014 17:00:04 +0000 (-0400)
Subject: doc: Suggesting clearing pg_replslot from a hot filesystem backup.
X-Git-Tag: REL9_4_BETA1~180
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=69671ab548459814d489315bf5cd421f84e984a4;p=postgresql

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 854b5fde41..06f064e1a6 100644
--- 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