Re: Problem with PITR recovery - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Problem with PITR recovery
Date
Msg-id 200504181502.j3IF2hh27780@candle.pha.pa.us
Whole thread Raw
In response to Re: Problem with PITR recovery  (Rob Butler <crodster2k@yahoo.com>)
Responses Re: Problem with PITR recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
OK, I updated the two current TODO items:* Allow point-in-time recovery to archive partially filled write-ahead  logs
Currentlyonly full WAL files are archived. This means that the most  recent transactions aren't available for recovery
incase of a disk  failure.  This could be triggered by a user command or a timer.* Automatically force archiving of
partially-filledWAL files when  pg_stop_backup() is called or the server is stopped  Doing this will allow
administratorsto know more easily when the  archive contins all the files needed for point-in-time recovery.
 

Is this OK?

---------------------------------------------------------------------------

Rob Butler wrote:
> 
> > I'd say it's very not cool :) It's not we all
> > expected from PITR.
> > I recall now Simon mentioned about that and have it
> > in his TODO.
> > Other thing I don't understand what's the problem to
> > generate WAL file
> > by demand ? Probably, TODO should says about this.
> 
> This would definetly be a good feature to have.  What
> I would prefer is:
> 
> 1) have the pitr stop command write out and close the
> WAL that it is currently using.
> 
> 2) have another stored proc which can be invoked at
> any time that will write out and close the WAL that is
> currently in use when that command is executed.
> 
> 3) have a feature in postgres that will automatically
> write out and close the WAL if the server hasn't had
> any activity in XX minutes, or hasn't closed a WAL
> file in XX minutes.
> 
> The reason for this is "the Friday night" scenario.
> 
> Let's say you have your WAL's FTP'd to a remote server
> off-site.  Friday at 4:50 PM Postgres starts a new
> WAL, and everyone goes home for the weekend at 5pm. 
> No activity occurs on the database all weekend long,
> so the new WAL never fills and is never closed.  If
> something should happen during the weekend, and the
> disks are ruined on the PG DB server, the last WAL is
> never sent to the remote off-site server.  The last
> transactions of the day are lost, even though they
> could have taken place days ago.  With feature 3, you
> can guarantee that the oldest WAL is XX minutes old,
> so at least you have all the transactions within the
> last XX minutes.
> 
> Of course feature #3 also needs to have some smarts to
> it, so it doesn't create a bunch of completely empty
> WAL's everytime the timer runs out.  It should only
> write and close the WAL if there is actually some new
> data in it.
> 
> Later
> Rob
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Problem with PITR recovery
Next
From: Bruce Momjian
Date:
Subject: Re: Problem with PITR recovery