Jim Nasby wrote:
> On Jun 17, 2007, at 4:39 AM, Simon Riggs wrote:
>>>> pg_start_backup() should be a normal checkpoint I think. No need for
>>>> backup to be an intrusive process.
>>>
>>> Good point. A spread out checkpoint can take a long time to finish,
>>> though. Is there risk for running into a timeout or something if it
>>> takes say 10 minutes for a call to pg_start_backup to finish?
>>
>> That would be annoying, but the alternative is for backups to seriously
>> effect performance, which would defeat the object of the HOT backup.
>> It's not like its immediate right now, so we'd probably be moving from
>> 2-3 mins to 10 mins in your example. Most people are expecting their
>> backups to take a long time anyway, so thats OK.
>
> We should document it, though; otherwise I can see a bunch of confused
> users wondering why pg_start_backup takes so long. Remember that with
> longer checkpoints, the odds of them calling pg_start_backup during one
> and having to wait are much greater.
If pg_start_backup initiates a non-immediate, smoothed checkpoint, how
about a checkpoint that's in progress when pg_start_backup is called?
Should that be hurried, so we can start the backup sooner? Probably not,
which means we'll need yet another mode to RequestCheckpoint: request a
non-immediate checkpoint, but if there's a checkpoint already running,
don't rush it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
