Re: Load Distributed Checkpoints, revised patch
От | Heikki Linnakangas |
---|---|
Тема | Re: Load Distributed Checkpoints, revised patch |
Дата | |
Msg-id | 4677C648.6010401@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Load Distributed Checkpoints, revised patch (Jim Nasby <decibel@decibel.org>) |
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: