On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> I don't see what difference it makes which process does the I/O. If a >> write() by checkpointer process blocks, any write()s by the separate >> bgwriter process at that time will block too. If the I/O is not saturated, >> and the checkpoint write()s don't block, then even without this patch, the >> bgwriter process can handle its usual bgwriter duties during checkpoint just >> fine. (And if the I/O is not saturated, it's not an I/O bound system >> anyway.) > > Whatever value you assign to the bgwriter, then this patch makes sure > that happens during heavy fsyncs.
I think his point is that it doesn't because if the heavy fsyncs cause the system to be i/o bound it then bgwriter will just block issuing the writes instead of the fsyncs. I'm not actually convinced. Writes will only block if the kernel decides to block. We don't really know how the kernel makes this decision but it's entirely possible that having pending physical i/o issued due to an fsync doesn't influence the decision if there is still a reasonable number of dirty pages in the buffer cache. In a sense, "I/O bound" means different things for write and fsync. Or to put it another way fsync is latency sensitive but write is only bandwidth sensitive. All that said my question is which way is the code more legible and easier to follow? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
