Re: Analysis of ganged WAL writes

"Curtis Faith" <curtis(at)galtair(dot)com> writes:
>> Well, too bad. If you haven't gotten your commit record down to disk,
>> then *you have not committed*. This is not negotiable. (If you think
>> it is, then turn off fsync and quit worrying ;-))

> I've never disputed this, so if I seem to be suggesting that, I've beee
> unclear. I'm just assuming that the disk can get a confirmation back to the
> INSERTing process in much less than one rotation.

You've spent way too much time working with lying IDE drives :-(

Do you really trust a confirm-before-write drive to make that write if
it loses power? I sure don't.

If you do trust your drive to hold that data across a crash, then ISTM
the whole problem goes away anyway, as writes will "complete" quite
independently of disk rotation. My Linux box has no problem claiming
that it's completing several thousand TPS with a single client ... and
yes, fsync is on, but it's using an IDE drive, and I don't know how to
disable confirm-before-write on that drive. (That's why I did these
tests on my old slow HP hardware.) Basically, the ganging of commit
writes happens inside the disk controller on a setup like that. You
still don't need aio_write --- unless perhaps to reduce wastage of IDE
bus bandwidth by repeated writes, but that doesn't seem to be a scarce
resource in this context.

regards, tom lane