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 <dmitry@xxxxxxxxxxx> 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
