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