"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.
regards, tom lane
