Dimitri Fontaine wrote:
Mark Kirkwood <mark.kirkw...@catalyst.net.nz> writes:
I've been using the wiki page
(http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and I
notice that it recommends the master (and replicas) have a non-trivial
archive_command even after the backup step is completed. ISTM that after the
backup the master's archive_command can be set to '' or '/bin/true' as the
walsender does not make any use of the WAL archive (AFAICS anyway). Clearly
it might be desirable to have the archived segments around for other reasons
- but equally it might be desirable *not* to have to have to (e.g disk
space), or am I overlooking something?
I think it's still necessary in the case the connection between a slave
and the master breaks. If the transient error is long enough for the
slave requesting WALs that the master no longer has, restore_command
will get used.
IIUC from the mails here, the restore_command is run directly by the
slave itself, so it needs to have access to master archives embedded in
the restore_command.
Take all this with a huge grain of salt, that's my understanding without
having had the time to read the patch or play with it yet.
Thanks Dimitri, I'd missed that thread. Ok, slave will need a suitable
restore_comand in addition to primary_conninfo in recovery.conf, and
then extended communication failures (or shutting down the slave for a
while!) will not break the streaming setup (FWIW I tried this just now).
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
