From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ivan Zolotukhin <ivan(dot)zolotukhin(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_start_backup() takes too long |
Date: | 2008-09-29 14:03:51 |
Message-ID: | 1222697031.4445.1238.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2008-09-29 at 08:35 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gauthier, Dave | 2008-09-29 14:17:19 | pl-pgsql, recursion and cursor contexting |
Previous Message | Tom Lane | 2008-09-29 13:55:35 | Re: error: |