doc: Update pg_receivexlog note

The old note about how to use pg_receivexlog as an alternative to
archive_command was obsoleted by replication slots.

diff --git a/doc/src/sgml/ref/pg_receivexlog.sgml b/doc/src/sgml/ref/pg_receivexlog.sgml
index 2ab392e82c275070e3fb73b1df9f5da819303952..74ed45db97ca0c3cd8917f9cc6f5724e27ba3627 100644 (file)
--- a/doc/src/sgml/ref/pg_receivexlog.sgml
+++ b/doc/src/sgml/ref/pg_receivexlog.sgml
@@ -324,17 +324,14 @@ PostgreSQL documentation
 
   
    When using pg_receivexlog instead of
-   , the server will continue to
-   recycle transaction log files even if the backups are not properly
-   archived, since there is no command that fails. This can be worked
-   around by having an  that fails
-   when the file has not been properly archived yet, for example:
-
-archive_command = 'sleep 5 && test -f /mnt/server/archivedir/%f'
-
-   The initial timeout is necessary because
-   pg_receivexlog works using asynchronous
-   replication and can therefore be slightly behind the master.
+    as the main WAL backup method, it is
+   strongly recommended to use replication slots.  Otherwise, the server is
+   free to recycle or remove transaction log files before they are backed up,
+   because it does not have any information, either
+   from  or the replication slots, about
+   how far the WAL stream has been archived.  Note, however, that a
+   replication slot will fill up the server's disk space if the receiver does
+   not keep up with fetching the WAL data.