271
>--status-interval=<TT
280
> Specifies the number of seconds between status packets sent back to the
281
server. This allows for easier monitoring of the progress from server.
282
A value of zero disables the periodic status updates completely,
283
although an update will still be sent when requested by the server, to
284
avoid timeout disconnect. The default value is 10 seconds.
309
>pg_receivexlog</SPAN
311
replication slot (see <A
312
HREF="warm-standby.html#STREAMING-REPLICATION-SLOTS"
315
When this option is used, <SPAN
317
>pg_receivexlog</SPAN
319
a flush position to the server, indicating when each segment has been
320
synchronized to disk so that the server can remove that segment if it
321
is not otherwise needed. When using this parameter, it is important
322
to make sure that <SPAN
324
>pg_receivexlog</SPAN
326
synchronous standby through an incautious setting of
328
HREF="runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES"
329
>synchronous_standby_names</A
331
data frequently enough for this to work correctly.
410
>--status-interval=<TT
419
> Specifies the number of seconds between status packets sent back to the
420
server. This allows for easier monitoring of the progress from server.
421
A value of zero disables the periodic status updates completely,
422
although an update will still be sent when requested by the server, to
423
avoid timeout disconnect. The default value is 10 seconds.
430
459
CLASS="REPLACEABLE"
502
531
connection attempt.
527
>pg_receivexlog</SPAN
529
replication slot (see <A
530
HREF="warm-standby.html#STREAMING-REPLICATION-SLOTS"
533
When this option is used, <SPAN
535
>pg_receivexlog</SPAN
537
a flush position to the server, indicating when each segment has been
538
synchronized to disk so that the server can remove that segment if it
539
is not otherwise needed. When using this parameter, it is important
540
to make sure that <SPAN
542
>pg_receivexlog</SPAN
544
synchronous standby through an incautious setting of
546
HREF="runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES"
547
>synchronous_standby_names</A
549
data frequently enough for this to work correctly.
637
619
HREF="runtime-config-wal.html#GUC-ARCHIVE-COMMAND"
638
620
>archive_command</A
639
>, the server will continue to
640
recycle transaction log files even if the backups are not properly
641
archived, since there is no command that fails. This can be worked
642
around by having an <A
621
> as the main WAL backup method, it is
622
strongly recommended to use replication slots. Otherwise, the server is
623
free to recycle or remove transaction log files before they are backed up,
624
because it does not have any information, either
643
626
HREF="runtime-config-wal.html#GUC-ARCHIVE-COMMAND"
644
627
>archive_command</A
646
when the file has not been properly archived yet, for example:
648
CLASS="PROGRAMLISTING"
649
>archive_command = 'sleep 5 && test -f /mnt/server/archivedir/%f'</PRE
651
The initial timeout is necessary because
654
>pg_receivexlog</SPAN
655
> works using asynchronous
656
replication and can therefore be slightly behind the master.
628
> or the replication slots, about
629
how far the WAL stream has been archived. Note, however, that a
630
replication slot will fill up the server's disk space if the receiver does
631
not keep up with fetching the WAL data.