Re: Backport of fsync queue compaction

Christopher Browne <cbbrowne@gmail.com>

From: Christopher Browne <cbbrowne@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-06-19T21:47:28Z
Lists: pgsql-hackers
On Tue, Jun 19, 2012 at 5:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jun 19, 2012 at 5:33 PM, Greg Smith <greg@2ndquadrant.com> wrote:
>> In January of 2011 Robert committed 7f242d880b5b5d9642675517466d31373961cf98
>> to try and compact the fsync queue when clients find it full.  There's no
>> visible behavior change, just a substantial performance boost possible in
>> the rare but extremely bad situations where the background writer stops
>> doing fsync absorption.  I've been running that in production at multiple
>> locations since practically the day it hit this mailing list, with backports
>> all the way to 8.3 being common (and straightforward to construct).  I've
>> never seen a hint of a problem with this new code.
>
> I've been in favor of back-porting this for a while, so you'll get no
> argument from me.
>
> Anyone disagree?

I recall reviewing that; it seemed like quite a good change.  Me likes.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Try to avoid running with a full fsync request queue.