On 29 May 2012 17:58, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> Why do you think that doing this for all XLogFlush() callsites might
>> be problematic?
>
> Well, consider the one in the background writer, for example. That's
> just a periodic flush, so I see no benefit in having it acquire the
> lock and then wait some more. It already did wait. And what about
> the case where we're flushing while holding WALInsertLock because the
> buffer's full? Clearly waiting is useless in that case - nobody can
> join the group commit for exactly the same reason that we're doing the
> flush in the first place: no buffer space.
When I read this the first time, I was in full agreement.
On closer inspection neither point is valid, though both points were
worth considering.
> Well, consider the one in the background writer, for example. That's
> just a periodic flush, so I see no benefit in having it acquire the
> lock and then wait some more. It already did wait.
We use XLogBackgroundFlush() not XLogFlush() from background processes.
> And what about
> the case where we're flushing while holding WALInsertLock because the
> buffer's full? Clearly waiting is useless in that case - nobody can
> join the group commit for exactly the same reason that we're doing the
> flush in the first place: no buffer space.
We don't flush WAL in that case, we just write it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services