From 342bcee4aa142ce4b119838a4c5d6debd694539f Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Fri, 7 Nov 2014 20:15:22 -0500 Subject: [PATCH] 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. --- doc/src/sgml/ref/pg_receivexlog.sgml | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/doc/src/sgml/ref/pg_receivexlog.sgml b/doc/src/sgml/ref/pg_receivexlog.sgml index be26b84c1b..97d2408d33 100644 --- a/doc/src/sgml/ref/pg_receivexlog.sgml +++ b/doc/src/sgml/ref/pg_receivexlog.sgml @@ -282,17 +282,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.