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

The Windows driver knows abotu the write cache, and at least fsync()
pushes through the write cache even if it's there. This seems to
indicate taht O_SYNC at least partiallyi does this as well. This is why
there is no performance difference at all on fsync() with write cache on
or off.

I don't know if this is true for all IDE disks. COuld be that my disk is
particularly well-behaved.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster