Re: [PATCHES] Doc update for pg_start_backup
От | Heikki Linnakangas |
---|---|
Тема | Re: [PATCHES] Doc update for pg_start_backup |
Дата | |
Msg-id | 4684C1E8.7020803@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCHES] Doc update for pg_start_backup (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Doc update for pg_start_backup
Re: [PATCHES] Doc update for pg_start_backup |
Список | pgsql-hackers |
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. > 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. To be honest, I've never worked as a DBA and never had to deal with taking backups of a production system, so my gut feelings on this could be totally wrong. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: