On Jun 29, 2007, at 3:25 AM, Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Heikki Linnakangas <heikki@enterprisedb.com> 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 jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)