Thread: Re: [pgsql-hackers-win32] win32 performance - fsync question

>> * 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

"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