On 29 May 2012 17:58, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan <pe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
