Re: Review: compact fsync request queue on overflow

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review: compact fsync request queue on overflow
Date: 2011-01-21 16:47:04
Message-ID: AANLkTi=vLND_iS+5XRm2aeREpehszF4COj8DH6qBv6G7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Quite.  It's taken me 12 days of machine time running pgbench to find the
> spots where this problem occurs on a system with a reasonably sized
> shared_buffers (I'm testing against 256MB).  It's one of those things it's
> hard to reproduce with test data.
>
> Thanks for the thorough code review.  I've got a clear test plan I'm
> progressing through this week to beat on the performance measurement aspects
> of the patch.

Any update on this? I think the test results you've posted previously
- particularly, the fact that when the queue fills up, there are
always many duplicates - is pretty much sufficient for us to convince
ourselves that this will provide a benefit in cases where that occurs.
And, in cases where the queue doesn't fill up, we'll never hit the
test that triggers this code, so it seems pretty clear there won't be
a negative impact there either. I don't want to rush your testing
process, but if it's already fairly clear that this will have some
benefit, I think it would be good to get it committed and move on to
working on the parts we're less sure about, like sorting writes and
spreading fsyncs, where we will probably need a lot more testing than
here to be sure that we have the right behavior.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-21 16:47:23 Re: More detailed auth info
Previous Message Tom Lane 2011-01-21 16:45:55 Re: sepgsql contrib module