Re: [pgsql-hackers-win32] SRA Win32 sync() code
От | Kurt Roeckx |
---|---|
Тема | Re: [pgsql-hackers-win32] SRA Win32 sync() code |
Дата | |
Msg-id | 20031119200734.GA8685@ping.be обсуждение исходный текст |
Ответ на | Re: [pgsql-hackers-win32] SRA Win32 sync() code (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-patches |
On Mon, Nov 17, 2003 at 12:46:34AM -0500, Bruce Momjian wrote: > Tom Lane wrote: > > > Do we know that having the background writer fsync a file that was > > > written by a backend cause all the data to fsync? I think I could write > > > a program to test this by timing each of these tests: > > > > That might prove something about the particular platform you tested it > > on; but it would not speak to the real problem, which is what we can > > assume is true on every platform... > > The attached program does test if fsync can be used on a file descriptor > after the file is closed and then reopened. I see: > > write 0.000613 > write & fsync 0.001727 > write, close & fsync 0.001633 > Does anyone have a platform where the last duration is significantly > different from the middle timing? write 0.002807 write & fsync 0.015248 write, close & fsync 0.004696 This is a Linux 2.6.0-test5 on an old IDE disk. The results change alot. An other result shows: write 0.002737 write & fsync 0.006658 write, close & fsync 0.008431 The first time is stable, the other 2 aren't. Averagly write & fsync would be about twice as big/slow as write, close & fsync. PS: Please specify some modes when creating files. Kurt
В списке pgsql-patches по дате отправления: