Skip to content

Commit 342bcee

Browse files
committed
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.
1 parent f36f4fb commit 342bcee

File tree

1 file changed

+8
-11
lines changed

1 file changed

+8
-11
lines changed

doc/src/sgml/ref/pg_receivexlog.sgml

Lines changed: 8 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -282,17 +282,14 @@ PostgreSQL documentation
282282

283283
<para>
284284
When using <application>pg_receivexlog</application> instead of
285-
<xref linkend="guc-archive-command">, the server will continue to
286-
recycle transaction log files even if the backups are not properly
287-
archived, since there is no command that fails. This can be worked
288-
around by having an <xref linkend="guc-archive-command"> that fails
289-
when the file has not been properly archived yet, for example:
290-
<programlisting>
291-
archive_command = 'sleep 5 &amp;&amp; test -f /mnt/server/archivedir/%f'
292-
</programlisting>
293-
The initial timeout is necessary because
294-
<application>pg_receivexlog</application> works using asynchronous
295-
replication and can therefore be slightly behind the master.
285+
<xref linkend="guc-archive-command"> as the main WAL backup method, it is
286+
strongly recommended to use replication slots. Otherwise, the server is
287+
free to recycle or remove transaction log files before they are backed up,
288+
because it does not have any information, either
289+
from <xref linkend="guc-archive-command"> or the replication slots, about
290+
how far the WAL stream has been archived. Note, however, that a
291+
replication slot will fill up the server's disk space if the receiver does
292+
not keep up with fetching the WAL data.
296293
</para>
297294

298295
</refsect1>

0 commit comments

Comments
 (0)