> "Magnus Hagander" <[EMAIL PROTECTED]> writes: >> My results are: >> Fisrt, baseline: >> * Linux, with fsync (default), write-cache disabled: no data corruption >> * Linux, with fsync (default), write-cache enabled: usually no data >> corruption, but two runs which had > > That makes sense. > >> * Win32, with fsync, write-cache disabled: no data corruption >> * Win32, with fsync, write-cache enabled: no data corruption >> * Win32, with osync, write cache disabled: no data corruption >> * Win32, with osync, write cache enabled: no data corruption. Once I >> got: >> 2005-02-24 12:19:54 LOG: could not open file "C:/Program >> Files/PostgreSQL/8.0/data/pg_xlog/000000010000000000000010" (log file 0, >> segment 16): No such file or directory >> but the data in the database was consistent. > > It disturbs me that you couldn't produce data corruption in the cases > where it theoretically should occur. Seems like this is an indication > that your test was insufficiently severe, or that there is something > going on we don't understand. > I was thinking about that. A few years back, Microsoft had some serious issues with write caching drives. They were taken to task for losing data if Windows shut down too fast, especially on drives with a large cache.
MS is big enough and bad enough to get all the info they need from the various drive makers to know how to handle write cache flushing. Even the stuff that isn't documented. If anyone has a very good debugger and/or emulator or even a logic analyzer, it would be interesting to see if MS sends commands to the drives after a disk write or a set of disk writes. Also, I would like to see this test performed on NTFS and FAT32, and see if you are more likely to lose data on FAT32. ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])