Re: [pgsql-hackers-win32] win32 performance - fsync question
От | Michael Paesold |
---|---|
Тема | Re: [pgsql-hackers-win32] win32 performance - fsync question |
Дата | |
Msg-id | 011c01c52ac0$13fc5ac0$0f01a8c0@zaphod обсуждение исходный текст |
Ответ на | Re: [pgsql-hackers-win32] win32 performance - fsync question (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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 по дате отправления: