On Jun 29, 2007, at 3:25 AM, Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Added a note to the docs that pg_start_backup can take a long
time to finish now that we spread out checkpoints:
I was starting to wordsmith this, and then wondered whether it's not
just a stupid idea for pg_start_backup to act that way. The reason
you're doing it is to take a base backup, right? What are you going
to take the base backup with? I do not offhand know of any backup
tools that don't suck major amounts of I/O bandwidth.
scp over a network? It's still going to consume a fair amount of I/
O, but the network could very well be the bottleneck.
You can also use rsync and have it do bandwidth limiting (AFAIK that
would work locally too).
That being
the case, you're simply not going to schedule the operation during
full-load periods. And that leads to the conclusion that
pg_start_backup should just use CHECKPOINT_IMMEDIATE and not slow
you down.
That's probably true in most cases. But on a system that doesn't
have quite periods, you're still going to have to take the backup.
Correct. If the load presented by the base backup is too high, you'll
be looking at ways to slow it down; but I've yet to run across such a
case in the field.
I think having start_backup do a checkpoint immediate by default
would be best, since it's least surprising, but I do like having it
as an option for cases where it's needed (though I think those cases
are probably pretty rare).
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
