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

From Michael Paesold
Subject Re: [pgsql-hackers-win32] win32 performance - fsync question
Date
Msg-id 011c01c52ac0$13fc5ac0$0f01a8c0@zaphod
Whole thread Raw
In response to Re: [pgsql-hackers-win32] win32 performance - fsync question  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian wrote:

> Michael Paesold wrote:
>> Magnus Hagander wrote:
[snip]

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

I was just seeing his error message below...

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

A missing xlog file does not strike me as "very save". Perhaps someone can
explain what happened, but I would not feel good about this. Again this note
(from Tom Lane) in combination with the above error would tell me, we don't
fully understand the risk here.

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

We both based our understanding on the same evidence. It seems we just have
a different level of paranoia. ;-)

Best Regards,
Michael Paesold


pgsql-hackers by date:

Previous
From: Shachar Shemesh
Date:
Subject: Re: type unknown - how important is it?
Next
From: "Magnus Hagander"
Date:
Subject: Re: Changing the default wal_sync_method to open_sync for Win32?