| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| 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 12:35:37 |
| Message-ID: | 10113.1222691737@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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. The checkpoint code is too complicated already;
I don't want to make it support a third behavior. And I'd vote against
taking out the current default behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Glyn Astill | 2008-09-29 13:23:09 | Re: Replication using slony-I |
| Previous Message | A. Kretschmer | 2008-09-29 12:28:25 | Re: access public relation from a private database |