From: | "Michael Paesold" <mpaesold(at)gmx(dot)at> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
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 07:07:59 |
Message-ID: | 011c01c52ac0$13fc5ac0$0f01a8c0@zaphod |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-hackers-win32 |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2005-03-17 08:44:59 | Re: Changing the default wal_sync_method to open_sync for Win32? |
Previous Message | Shachar Shemesh | 2005-03-17 07:04:05 | Re: type unknown - how important is it? |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2005-03-17 08:44:59 | Re: Changing the default wal_sync_method to open_sync for Win32? |
Previous Message | Marc G. Fournier | 2005-03-17 05:32:20 | Re: Changing the default wal_sync_method to open_sync for |