On Thu, 2005-12-29 at 10:47 +0300, Dmitry Panov wrote:
On Wed, 2005-12-28 at 11:05 -0500, Tom Lane wrote:
Dmitry Panov [EMAIL PROTECTED] writes:
Yes, but if the server has crashed earlier the script won't be called
and if the filesystem can't be recovered the changes will be lost. My
point is the server should write into both (or more) files at the same
time.
As for that, I agree with the other person: a RAID array does that just
fine, and with much higher performance than we could muster.
BTW, I found something related in the TODO:
http://momjian.postgresql.org/cgi-bin/pgtodo?pitr
I think both approaches have the right to exist, but I prefer my because
it looks more straightforward, it insures up-to-date recovery (no
delays) and it reduces the traffic (as the partial logs have to be
transferred in full by the proposed archive_current_wal_command). The
only drawback is performance.
Simply replicating pg_xlog might be worthwhile for the truly paranoid,
since it does help in the situation that you lose the RAID unit with
your pg_xlog on it. But this facility is already available via hardware
replication facilities, so I see no reason to build it into the DBMS.
Replicating pg_xlog to NFS would not work very well performance wise and
has some major undefined behaviour in most failure modes, so I would
never do that.
However, there is a case to be made for continuous xlog record
archival which could get closer to 0% data loss in the event of
failure, though with higher performance hit than current PITR. I'll look
into that some more - but no promises.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: explain analyze is your friend
