Re: Final(?) proposal for wal_sync_method changes
От | Tom Lane |
---|---|
Тема | Re: Final(?) proposal for wal_sync_method changes |
Дата | |
Msg-id | 2412.1291770433@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Final(?) proposal for wal_sync_method changes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Final(?) proposal for wal_sync_method changes
Re: Final(?) proposal for wal_sync_method changes |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: >>> I am unclear as to the reason why there is a test for >>> HAVE_FSYNC_WRITETHROUGH_ONLY in pg_fsync(). Perhaps that is also >>> leftover from a previous vision of how this all works? Or does an >>> fsync() call actually fail on Windows? >> No, fsync responds fine. It just don't actually sync to disk. Sigh ... The closer I look at the Windows code path here, the more of an inconsistent, badly documented spaghetti-heap it appears to be. So far as a quick Google search unearths, there is no fsync() primitive on Windows. What we have actually got is this gem in port/win32.h: /** Even though we don't support 'fsync' as a wal_sync_method,* we do fsync() a few other places where _commit() isjust fine.*/ #define fsync(fd) _commit(fd) So actually, there is no difference between selecting fsync and fsync_writethrough on Windows, this comment and the SGML documentation to the contrary. Both settings result in invoking _commit() and presumably are safe. One wonders why we bothered to invent a separate fsync_writethrough setting on Windows. What this means is that switching to a simple preference order "fdatasync, then fsync" will result in choosing fsync on Windows (since it hasn't got fdatasync), meaning _commit, meaning Windows users see a behavioral change after all. I'm afraid that if we don't want a major behavioral change, there's no option except having a Windows-specific rule for the choice of default. It'll have to be "fdatasync, then fsync, except on Windows where open_datasync is the default". Grumble. But it's not like Windows hasn't got a hundred other special cases already. Would someone verify via pgbench or similar test (*not* test_fsync) that on Windows, wal_sync_method = fsync or fsync_writethrough perform the same (ie tps ~= disk rotation rate) while open_datasync is too fast to be real? I'm losing confidence that I've found all the spaghetti ends here, and I don't have a Windows setup to try it myself. regards, tom lane
В списке pgsql-hackers по дате отправления: