On Thu, 2007-06-28 at 23:35 -0400, 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. That being > the case, you're simply not going to schedule the operation during > full-load periods.
Well, that assumes you can predict a time of reduced load and that time critical activities won't happen at that point. Many times you can, but I see no reason to force a checkpoint immediate. If you use snapshots you can copy the data away in your own time, so not all backup mechanisms draw extensive/high priority I/O power. > And that leads to the conclusion that > pg_start_backup should just use CHECKPOINT_IMMEDIATE and not slow > you down. I would prefer the default to be do this slowly. If there is a reason to do it fast, maybe, but we should err towards low impact. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
