On 20.09.2011 16:29, Greg Stark wrote:
> On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs<simon@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.
Yeah, I was thinking of write()s, not fsyncs. I agree this might have
some effect during fsync phase.
> All that said my question is which way is the code more legible and
> easier to follow?
Hear hear. If we're going to give the bgwriter more responsibilities,
this might make sense even if it has no effect on performance.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com