Re: Documentation on PITR still scarce - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Documentation on PITR still scarce
Date
Msg-id 1099870342.6942.3186.camel@localhost.localdomain
Whole thread Raw
In response to Re: Documentation on PITR still scarce  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
On Sun, 2004-11-07 at 20:26, Greg Stark wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > I suppose it might be useful to have some kind of "suspended animation"
> > behavior where you could bring up a backend and look at the database in
> > a strict read-only fashion, not really executing transactions at all,
> > just to see what you had.  Then you could end the recovery and go to
> > normal operations, or allow the recovery to proceed further if you
> > decided this wasn't where you wanted to be yet.  However that would
> > require a great deal of mechanism we haven't got (yet).  In particular
> > there is no such thing as strict read-only examination of the database.
> 
> That would be a great thing to have one day for other reasons aside from the
> ability to test out a recovered database. It makes warm standby databases much
> more useful.
> 
> A warm standby is when you keep a second machine constantly up to date by
> applying the archived PITR logs as soon as they come off your server. You're
> ready to switch over at the drop of a hat and don't have to go through the
> whole recovery process, you just switch the database from recovery mode to
> active mode and make it your primary database. 
> 

Agreed, its all possible, just more code.

> Oracle has had a feature for a long time that you can actually open the
> standby database in a strict read-only mode and run queries. This is great for
> a data warehouse situation where you want to run long batch jobs against
> recent data.

"for a long time" is somewhat subjective... I still remember the time
before clearly enough, so will many potential PostgreSQL users.

There's a huge range of features we can implement eventually and they
certainly aren't limited to ones Oracle implemented before us. There are
some PostgreSQL unique features to exploit yet.

-- 
Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Increasing the length of
Next
From: Rod Taylor
Date:
Subject: Error: set log_error_verbosity to verbose fails