Re: fsync vs open_sync (more info)
От | pgsql@mohawksoft.com |
---|---|
Тема | Re: fsync vs open_sync (more info) |
Дата | |
Msg-id | 11115.64.119.142.34.1092151370.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | fsync vs open_sync (pgsql@mohawksoft.com) |
Ответы |
Re: fsync vs open_sync (more info)
|
Список | pgsql-hackers |
> > In particular, you need to offer some evidence for that completely > undocumented assertion that "it won't hurt anyone else". It should be easy enough to prove whether or not O_SYNC hurts anyone. OK, let me ask a few questions: (1) what is a good sample set on which to run? Linux, FreeBSD, MacIntosh? (2) What sort of tests would be definitive? Auto commit and some transactional load? After delving into this a little, it seems to me that if you are going to do this: write(file, buffer, size); f[data]sync(file); Opening with O_SYNC seems to be an optimization specifically to this methodology. At the very least, it will save one user/kernel transition. If we can prove beyond a reasonable doubt that using O_SYNC does not hurt any platform, then what reason would there be to continue making it the default? Again, conceptually, O_SYNC does what you want it to do, and should be able to do it more efficiently than fdatasync().
В списке pgsql-hackers по дате отправления: