Skip to content

Commit 69671ab

Browse files
committed
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.
1 parent c050b2a commit 69671ab

File tree

1 file changed

+15
-0
lines changed

1 file changed

+15
-0
lines changed

doc/src/sgml/backup.sgml

+15
Original file line numberDiff line numberDiff line change
@@ -943,6 +943,21 @@ SELECT pg_stop_backup();
943943
(These files can confuse <application>pg_ctl</>.)
944944
</para>
945945

946+
<para>
947+
It is often a good idea to also omit from the backup dump the files
948+
within the cluster's <filename>pg_replslot/</> directory, so that
949+
replication slots that exist on the master do not become part of the
950+
backup. Otherwise, the subsequent use of the backup to create a standby
951+
may result in indefinite retention of WAL files on the standby, and
952+
possibly bloat on the master if hot standby feedback is enabled, because
953+
the clients that are using those replication slots will still be connecting
954+
to and updating the slots on the master, not the standby. Even if the
955+
backup is only intended for use in creating a new master, copying the
956+
replication slots isn't expected to be particularly useful, since the
957+
contents of those slots will likely be badly out of date by the time
958+
the new master comes on line.
959+
</para>
960+
946961
<para>
947962
It's also worth noting that the <function>pg_start_backup</> function
948963
makes a file named <filename>backup_label</> in the database cluster

0 commit comments

Comments
 (0)