Michael Paesold wrote:
> Magnus Hagander wrote:
>
>
> >> Magnus Hagander wrote:
> >>> > 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.
> [snip]
>
> > Michael Paesold wrote:
> >>The original patch did not have any documentation. Have you
> >>added some? Since this has to be configured in GUC (wal_sync_method),
> >>the implications should be documented somewhere, no?
>
> >The patch just implements behaviour that was already documented (for
> >unix) on a new platform (win32). The documentation in general appears >to
> >have very little information on what to pick there, though ;-)
>
> Reading your mails about the pull-the-plug tests, I see that at least with
> write caching enabled, fsync is more secure on win32 than open_sync. I.e.
> one should disable write caching for use with open_sync. Also open_sync
> seems to perform much better. All that information would be nice to have in
> the docs.
Michael, I am not sure why you come to the conclusion that open_sync
requires turning off the disk write cache. I saw nothing to indicate
that in the thread:
http://archives.postgresql.org/pgsql-hackers-win32/2005-02/msg00035.php
I read the following:
> > > * 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.
This indicated to me that open_sync did not require any additional
changes than our current fsync.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
