Re: pg_start_backup() takes too long - Mailing list pgsql-general

From Simon Riggs
Subject Re: pg_start_backup() takes too long
Date
Msg-id 1222697031.4445.1238.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: pg_start_backup() takes too long  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_start_backup() takes too long  (Bruce Momjian <bruce@momjian.us>)
List pgsql-general
On Mon, 2008-09-29 at 08:35 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > I'm surprised that checkpoint smoothing moves slowly even when it has so
> > little to do.
>
> AFAIK that's operating as designed.  The point being that we shouldn't
> create any more I/O load than we absolutely have to.
>
> It's not clear to me that it's a bug for pg_start_backup to take awhile.

> If it is a bug then I'd vote for just making it do an immediate
> checkpoint --- that might cause big I/O load but it's hardly likely to
> be worse than what will happen when you start taking the subsequent
> filesystem backup.

It was a clear intention for it to *not* cause a spike if we could avoid
it. The idea was if you wanted it to happen quickly then you could do a
checkpoint command first... oh well.

People might want to I/O limit the backup also, which they can do
without needing to let us know.

I'm happy to put an option in for this, so we have another function:
pg_start_backup(label text, immediate_chkpt boolean). I'll not be
rushing to do this though given my current TODO.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: error:
Next
From: "Gauthier, Dave"
Date:
Subject: pl-pgsql, recursion and cursor contexting