>> * Linux, with fsync (default), write-cache enabled: usually no data
>> corruption, but two runs which had
>
>Are you verifying that all the data that was committed was
>actually stored? Or
>just verifying that the database works properly after rebooting?

I verified the data.


>I'm a bit surprised that the write-cache lead to a corrupt
>database, and not
>merely lost transactions. I had the impression that drives
>still handled the
>writes in the order received.

In this case, it was lost transactions, not data corruption. Should be
more careful. I had copy/pasted the "no data corruption", should specify
what was lost.

A couple of the latest transactions were gone, but the database came up
in a consistent state, if a bit old.

Since Linux wasn't the stuff I actually was testing, I didn't run very
many tests on it though.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

"Magnus Hagander" <mha@sollentuna.net> writes:

> > I'm a bit surprised that the write-cache lead to a corrupt database, and
> > not merely lost transactions. I had the impression that drives still
> > handled the writes in the order received.
>
> In this case, it was lost transactions, not data corruption.
> ...
> A couple of the latest transactions were gone, but the database came up
> in a consistent state, if a bit old.

That's interesting. It would be very interesting to know how reliably this is
true. It could potentially vary depending on the drive firmware.

I can't see any painless way to package up this kind of test for people to run
though. Powercycling machines repeatedly really isn't fun and takes a long
time. And testing this on vmware doesn't buy us anything.

--
greg


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match