From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Documentation on PITR still scarce |
Date: | 2004-11-29 13:10:57 |
Message-ID: | 200411291310.iATDAve28850@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Or TODO maybe worded as:
* Allow the PITR process to be debugged and data examined
---------------------------------------------------------------------------
Simon Riggs wrote:
> On Mon, 2004-11-29 at 02:20, Bruce Momjian wrote:
>
> > Is this a TODO?
>
> Yes, but don't hold your breath on that feature.
>
> Gavin and I were discussing briefly a design that would allow something
> similar to this. The design would allow the user to stop/start recovery
> and turn a debug trace on/off, in a gdb-like mode. Thats a lot easier to
> implement than the proposal below, which I agree is desirable. We
> haven't hardly started that discussion yet though.
> I called this "recovery console" functionality.
>
> I'm not sure I like the Suspended Animation phrase, I thought maybe
> TARDIS or Langston Field sums it up better (kidding...)
>
> > Greg Stark wrote:
> > >
> > > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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. But in the until then the
> > > backup hardware languishes, completely useless.
> > >
> > > 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.
> > >
> > > --
> > > greg
> > >
> --
> Best Regards, Simon Riggs
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-11-29 13:13:56 | Re: [pgsql-www] pg_autovacuum is nice ... but ... |
Previous Message | Bruce Momjian | 2004-11-29 13:09:57 | Re: Documentation on PITR still scarce |