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