Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

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