From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Streaming Replication and archiving |
Date: | 2010-01-19 22:35:40 |
Message-ID: | m2hbqh7mf7.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)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.
Regards,
--
dim
PS: maybe the states and transitions and what data flows from where to
where in each of those would be good at least in the documentation, if
not explicit in the code?
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-01-19 22:37:36 | Re: MySQL-ism help patch for psql |
Previous Message | Joshua D. Drake | 2010-01-19 22:34:54 | Re: Mammoth in Core? |