From: Michael Paquier [mailto:michael@paquier.xyz]
> One of the reasons why I have begun this thread is that since we have heard
> about the fsync issues on Linux, I think that there is room for giving our
> user base more control of their fate without relying on the Linux community
> decisions to potentially eat data and corrupt a cluster with a page dirty
> bit cleared without its data actually flushed. Even the latest kernels
> are not fixing all the patterns with open fds across processes, switching
> the problem from one corner of the table to another, and there are folks
> patching the Linux kernel to make Postgres more reliable from this
> perspective, and living happily with this option. As long as the option
> can be controlled and defaults to false, it seems to be that we could do
> something. Even if the performance is bad, this gives the user control
> of how he/she wants things to be done.
Thank you for starting an interesting topic. We probably want the direct I/O. On a INSERT and UPDATE heavy system
withPostgreSQL 9.2, we suffered from occasional high response times due to the Linux page cache activity. Postgres
processescompeted for the page cache to read/write the data files, write online and archive WAL files, and write the
serverlog files (auto_explain and autovacuum workers emitted a lot of logs.) The user with Oracle experience asked why
PostgreSQLdoesn't handle database I/O by itself...
And I wonder how useful the direct I/O for low latency devices like the persistent memory. The overhead of the page
cachemay become relatively higher.
Regards
Takayuki Tsunakawa
