Scott Carey <scott@xxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
