Re: [PATCHES] Doc update for pg_start_backup
- From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
- To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgreSQL(dot)org>
- Subject: Re: [PATCHES] Doc update for pg_start_backup
- Date: Fri, 29 Jun 2007 08:04:45 +0100
- Message-id: <1183100685(dot)3589(dot)28(dot)camel(at)silverbirch(dot)site>
On Thu, 2007-06-28 at 23:35 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)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. 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
Home |
Main Index |
Thread Index