Re: PITR Backups
От | Dan Gorman |
---|---|
Тема | Re: PITR Backups |
Дата | |
Msg-id | 69DBDB50-8180-4A53-B753-61C06B2753C1@hi5.com обсуждение исходный текст |
Ответ на | Re: PITR Backups ("Simon Riggs" <simon@2ndquadrant.com>) |
Ответы |
Re: PITR Backups
|
Список | pgsql-performance |
Ah okay. I understand now. So how can I signal postgres I'm about to take a backup ? (read doc from previous email ? ) Regards, Dan Gorman On Jun 22, 2007, at 4:38 AM, Simon Riggs wrote: > On Fri, 2007-06-22 at 04:10 -0700, Dan Gorman wrote: >> This snapshot is done at the LUN (filer) level, postgres is un-aware >> we're creating a backup, so I'm not sure how pg_start_backup() plays >> into this ... > > Postgres *is* completely unaware that you intend to take a backup, > that > is *exactly* why you must tell the server you intend to make a backup, > using pg_start_backup() and pg_stop_backup(). That way Postgres will > flush its buffers, so that they are present on storage when you > make the > backup. > > Is the procedure for Oracle or any other transactional RDBMS any > different? > > -- > 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
В списке pgsql-performance по дате отправления: