Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Michael Paesold <mpaesold(at)gmx(dot)at>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org,pgsql-hackers-win32(at)postgresql(dot)org,Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Subject: Re: [pgsql-hackers-win32] win32 performance - fsync question
Date: 2005-03-17 04:29:09
Message-ID: 200503170429.j2H4T9E22207@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32
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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-03-17 04:31:59
Subject: Re: Changing the default wal_sync_method to open_sync for
Previous:From: Tom LaneDate: 2005-03-17 04:26:09
Subject: Re: Changing the default wal_sync_method to open_sync for Win32?

pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2005-03-17 04:31:59
Subject: Re: Changing the default wal_sync_method to open_sync for
Previous:From: Tom LaneDate: 2005-03-17 04:26:09
Subject: Re: Changing the default wal_sync_method to open_sync for Win32?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group