Re: Point in Time Recovery - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Point in Time Recovery
Date
Msg-id 1089837519.17493.4704.camel@stromboli
Whole thread Raw
In response to Re: Point in Time Recovery  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Responses Re: Point in Time Recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Point in Time Recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Mike Rylander
Date:
Subject: Re: Portals and nested transactions
Next
From: Oliver Jowett
Date:
Subject: Re: Portals and nested transactions