Re: pg_start_backup() takes too long

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_start_backup() takes too long
Date: 2008-09-29 21:49:26
Message-ID: Pine.GSO.4.64.0809291725170.16949@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 29 Sep 2008, Simon Riggs wrote:

> I'm surprised that checkpoint smoothing moves slowly even when it has so
> little to do. ISTM checkpoint completion target should set its write
> rate according to the thought that if shared_buffers were all dirty it
> would write them out in checkpoint_timeout *
> checkpoint_completion_target seconds. However, what it does is write
> them *all* out in that time, no matter how many dirty blocks there are.
> If there is just a few blocks to write, we take the *same* time to write
> them as if it were all dirty.

The checkpoint smoothing code that made it into 8.3 missed a couple of
nice to have features that just didn't make the schedule cut-off.
Enforcing a minimum rate was one, another was smoothing fsync calls.

Back when we were talking about the patch to sort writes at checkpoint
time, someone (I think you actually) commented that it might be worthwile
to create some sort of hook for making behavior of checkpoint-time dirty
buffer processing easy to change with a custom strategy. The sorted
behavior would then be the first such strategy available. Another one I
was thinking of was something that specified min+max write writes, which
would make this problem go away--might even auto-tune checkpoint_segments
or replace it altogether with an implementation based on those inputs.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tommy Gibbons 2008-09-29 21:52:52 dbsamples from pgfoundry
Previous Message postgres Emanuel CALVO FRANCO 2008-09-29 21:27:51 Re: [HACKERS] PostgreSQL future ideas