On Wed, Nov 18, 2009 at 8:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
You would still need it to guard against partial page writes, unless
we have some guarantee that those can't happen.
And once your transaction has scattered its transaction id into
various xmin and xmax over many tables, you need an atomic, durable
repository to decide if that id has or has not committed. Maybe clog
fsynced on commit would serve this purpose?
Jeff
