Re: Point in Time Recovery
От | Simon Riggs |
---|---|
Тема | Re: Point in Time Recovery |
Дата | |
Msg-id | 1089837519.17493.4704.camel@stromboli обсуждение исходный текст |
Ответ на | Re: Point in Time Recovery ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>) |
Ответы |
Re: Point in Time Recovery
Re: Point in Time Recovery |
Список | pgsql-hackers |
On Wed, 2004-07-14 at 10:57, Zeugswetter Andreas SB SD wrote: > > The recovery mechanism doesn't rely upon you knowing 1 or 3. The > > recovery reads pg_control (from the backup) and then attempts to > > de-archive the appropriate xlog segment file and then starts > > rollforward > > Unfortunately this only works if pg_control was the first file to be > backed up (or by chance no checkpoint happened after backup start and > pg_control backup) > > Other db's have commands for: > start/end external backup > OK...this idea has come up a few times. Here's my take: - OS and hardware facilities exist now to make instant copies of sets of files. Some of these are open source, others not. If you use these, you have no requirement for this functionality....but these alone are no replacement for archive recovery.... I accept that some people may not wish to go to the expense or effort to use those options, but in my mind these are the people that will not be using archive_mode anyway. - all we would really need to do is to stop the bgwriter from doing anything during backup. pgcontrol is only updated at checkpoint. The current xlog is updated constantly, but this need not be copied because we are already archiving it as soon as its full. That leaves the bgwriter, which is now responsible for both lazy writing and checkpoints. So, put a switch into bgwriter to halt for a period, then turn it back on at the end. Could be a SIGHUP GUC...or... ...and with my greatest respects.... - please could somebody else code that?... my time is limited Best regards, Simon Riggs
В списке pgsql-hackers по дате отправления: