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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Michael Paesold <mpaesold(at)gmx(dot)at>, 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 18:35:14
Message-ID: 200503171835.j2HIZEP05129@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-hackers-win32 pgsql-patches

Magnus Hagander wrote:
> > This indicated to me that open_sync did not require any
> > additional changes than our current fsync.
>
> fsync and open_sync both write through the write cache in the operating
> system. Only fsync=off turns this off.
>
> fsync also writes through the hardware write cache. o_sync does not.
> This is what causes the large slowdown with write cache enabled,
> *including* most battery backed write cache systems (pretty much making
> the write-cache a waste of money). This may be a good thing on IDE
> systems (for admins that don't know how to remove the little check in
> the box for "enable write caching on the disk" that MS provides, which
> *explicitly* warns that you may lose data if you enabled it), but it's a
> very bad thing for anything higher end.

I found the checkbox on XP looking at "Properties" for the drive, then
choosing "Hardware", the drive, "Properties", and "Policies".

> fsync also syncs the directory metadata. o_sync only cares about the
> files contents. (This is what causes the large slowdown with write cache
> *disabled*, because it requires multiple writes on multiple disk
> locations for each fsync).
>
> Basically, fsync hurts people who configure their box correctly, or who
> use things like SCSI disks. o_sync hurts people who configure their
> machine in an unsafe way.

So, it seems that Win32 open_sync is exactly the same as our
"wal_sync_method = open_datasync" on Unix (it needs to be renamed), and
"wal_sync_method = fsync" on Win32 is something we don't have that
writes through the disk write cache even if it is enabled.

I have developed the following patch which renames our wal_sync_method
Win32 support from open_sync to open_datasync:

ftp://candle.pha.pa.us/pub/postgresql/mypatches

One issue with this patch is that if applied it would make open_datasync
the default sync method on Win32 because we prefer open_datasync over
all other sync methods. If we don't want to do that, I think we should
still do the rename for accuracy and add a !WIN32 test to prevent
open_datasync from being the default.

However, I do prefer this patch and let Win32 have the same write cache
issues as Unix, for consistency.

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2005-03-17 18:36:29 Re: securing pg_proc
Previous Message Tom Lane 2005-03-17 18:31:52 Re: PHP stuff

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2005-03-17 18:41:00 Re: [pgsql-hackers-win32] win32 performance - fsync question
Previous Message Marc G. Fournier 2005-03-17 18:15:47 Re: Changing the default wal_sync_method to open_sync for

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-03-17 18:41:00 Re: [pgsql-hackers-win32] win32 performance - fsync question
Previous Message Tom Lane 2005-03-17 14:51:50 Re: WIP: avoiding tuple construction/deconstruction overhead