Tom Lane wrote:
> "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > One question, more directed to Tom here ... since they are seperate right
> > now, if WAL is fsync, and "regular writing" is no-fsync, doesn't that
> > potentially open us up to some *serious* problems? WAL sees the
> > transaction as complete, but the write for the rest of the system hasn't
> > happened yet?
>
> No, that's pretty much the whole point of WAL: once you've fsynced the
> transaction's log entries to WAL, it's committed. You don't have to
> fsync the data-file writes, or even write the changes out at all.
> (In most cases the pages stay in shared buffer cache, dirty, until the
> background writer gets to them.) If you crash then the data-file
> changes will get redone by replaying the WAL entries.
>
> You do have to fsync data-file writes when trying to complete a
> checkpoint, but that's outside the critical path for normal
> transactions.
>
> One of the reasons I dislike Bruce's proposal is that I don't think it
> pays any attention to this basic duality between normal operations
> (fsync WAL) and checkpoints (fsync data). We just finished finding a
> long-standing bug in this area, so I'm pretty hesitant to whack it
> around on the basis of unproven ideas about performance improvements.
I have to show some performance numbers to make it worthwhile.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073