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

> > Magnus prepared a trivial patch which added the O_SYNC flag for
> > windows and mapped it to FILE_FLAG_WRITE_THROUGH in win32_open.c.
>
> Attached is this trivial patch. As Merlin says, it needs some
> more reliability testing. But the numbers are at least reasonable - it
> *seems* like it's doing the right thing (as long as you turn
> off write cache). And it's certainly a significant
> performance increase - it brings the speed almost up to the
> same as linux.

I have now run a bunch of pull-the-plug testing on this patch (literally
pulling the plug, yes. to the point of some of my co-workers thinking
I'm crazy)

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

Almost all runs showed a line along the line:
2005-02-24 11:22:41 LOG: record with zero length at 0/A450548

In the final test, the BIOS decided the disk was giving up and
reassigned it as 0Mb.. Required two extra cold boots, then it was back
up to 20Gb. Still no data loss.

My tests was three clients doing lots of inserts and updates, some in
transactions some bare. In some tests, I kicked in a manual vacuum while
at it. Then I yanked the powercord, rebooted, manually started pg, and
verified taht the data in the db came up with the same values the cliens
reported as last committed. I also ran vacuum verbose on all tables
after it was back up to see if there were any warnings.

Test machine is a 1GHz Celeron, 256Mb RAM and a Maxtor IDE disk.

It'd of course be good if others could also test, but I'm getting the
feeling that this patch at least doesn't make things worse than before
:-) ANd it's *a lot* faster.

//Magnus