Scott Carey <scott@richrelevance.com> writes:
> For your database DATA disks, leaving the write cache on is 100% acceptable,
> even with power loss, and without a RAID controller. And even in high write
> environments.
Really? How hard have you tested that configuration?
> That is what the XLOG is for, isn't it?
Once we have fsync'd a data change, we discard the relevant XLOG
entries. If the disk hasn't actually put the data on stable storage
before it claims the fsync is done, you're screwed.
XLOG only exists to centralize the writes that have to happen before
a transaction can be reported committed (in particular, to avoid a
lot of random-access writes at commit). It doesn't make any
fundamental change in the rules of the game: a disk that lies about
write complete will still burn you.
In a zero-seek-cost environment I suspect that XLOG wouldn't actually
be all that useful. I gather from what's been said earlier that SSDs
don't fully eliminate random-access penalties, though.
regards, tom lane
