Skip site navigation (1) Skip section navigation (2)

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date: 2012-05-29 16:58:30
Message-ID: CA+TgmoaHjVVhcHSaq9=G-R9jYE7SurmF7HSoXFxxM019Omj0mQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-05-29 17:03:36
Subject: Re: pg_basebackup --xlog compatibility break
Previous:From: Robert HaasDate: 2012-05-29 16:55:08
Subject: Re: Bogus nestloop rows estimate in 8.4.7

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group