Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date
Msg-id CA+TgmoaHjVVhcHSaq9=G-R9jYE7SurmF7HSoXFxxM019Omj0mQ@mail.gmail.com
Whole thread Raw
In response to Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Bogus nestloop rows estimate in 8.4.7
Next
From: Robert Haas
Date:
Subject: Re: pg_basebackup --xlog compatibility break