Both added to TODO:
---
Simon Riggs wrote:
> On Mon, 2004-11-29 at 13:10, Bruce Momjian wrote:
> > Or TODO maybe worded as:
> >
> > * Allow the PITR process to be debugged and data examined
> >
>
> Yes, thats good fo
Simon Riggs <[EMAIL PROTECTED]> writes:
> Greg's additional request might be worded:
>
> * Allow a warm standby system to also allow read-only queries
Others have also asked in the past for a mode where a database could be run
off read-only media like a CD-ROM. I would phrase it more like
Simon Riggs wrote:
> On Mon, 2004-11-29 at 13:10, Bruce Momjian wrote:
>
>>Or TODO maybe worded as:
>>
>>* Allow the PITR process to be debugged and data examined
>>
>
>
> Yes, thats good for me...
>
> Greg's additional request might be worded:
>
>* Allow a warm standby system to also
On Mon, 2004-11-29 at 13:10, Bruce Momjian wrote:
> Or TODO maybe worded as:
>
> * Allow the PITR process to be debugged and data examined
>
Yes, thats good for me...
Greg's additional request might be worded:
* Allow a warm standby system to also allow read-only queries
Thanks
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 bre
OK, how would it be worded?
* Allow PITR recovery to a read-only server
---
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
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
Is this a TODO?
---
Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> 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 d
On Sun, 2004-11-07 at 20:26, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> 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 trans
Tom Lane <[EMAIL PROTECTED]> 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 co
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sun, 2004-11-07 at 11:15, Joachim Wieland wrote:
>> Ok, that seems to be pretty intuitive. But could one extend the recovery
>> mechanism such that one can go from PIT t_0 to PIT t_1 with t_1 > t_0
>> without re-restoring the original backup?
> Same que
On Sun, 2004-11-07 at 11:15, Joachim Wieland wrote:
> On Sat, Nov 06, 2004 at 07:17:29PM +, Simon Riggs wrote:
> > > > Once you have brought up a database in timeline N+1, you can't use it as
> > > > the base to recover to a point in timeline N because the data file
> > > > contents cannot be t
On Sat, Nov 06, 2004 at 07:17:29PM +, Simon Riggs wrote:
> > > Once you have brought up a database in timeline N+1, you can't use it as
> > > the base to recover to a point in timeline N because the data file
> > > contents cannot be trusted to be identical to the way they were in
> > > timelin
On Sat, 2004-11-06 at 15:03, Joachim Wieland wrote:
> Hi,
>
> On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote:
> > The timeline code only comes into effect when you request an archive
> > recovery. If you do not, it has no way of knowing it "should have".
>
> Ok. However these details
Hi,
On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote:
> The timeline code only comes into effect when you request an archive
> recovery. If you do not, it has no way of knowing it "should have".
Ok. However these details should be added to the docs as well.
At least a short warning sho
On Sat, 2004-11-06 at 00:54, Joachim Wieland wrote:
> Hi,
>
> On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote:
> > That is exactly the situation Timelines are designed to avoid. This
> > should not have happened. What leads you to think it has? My guess is
> > that it has not. If it ha
Hi,
On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote:
> That is exactly the situation Timelines are designed to avoid. This
> should not have happened. What leads you to think it has? My guess is
> that it has not. If it has, its a bug.
Hmm. I did the following:
- I recovered to one P
On Fri, 2004-11-05 at 18:10, Joachim Wieland wrote:
> My first mistake was that I kept the archive_command setting and thus
> overwrote my original archive files. Maybe you should add a note that one
> should set it to another directory when recovering.
>
That is exactly the situation Timelines
Simon,
thanks for that quick and detailed answer.
On Fri, Nov 05, 2004 at 05:42:01PM +0100, [EMAIL PROTECTED] wrote:
> The sample file gives additional information, just as occurs with
> pg_hba.conf. I don't see any need to replicate the sample file in the
> docs, do you?
Well, maybe one could a
Joachim Wieland <[EMAIL PROTECTED]> wrote on 05.11.2004, 16:28:38:
> Hi there,
>
> I just wanted to try the PITR feature in beta and got it working somehow.
> However I think the docs on this point are still not sufficient enough.
>
> We have to assume that people will have a closer look at the
Hi there,
I just wanted to try the PITR feature in beta and got it working somehow.
However I think the docs on this point are still not sufficient enough.
We have to assume that people will have a closer look at the backup/recovery
documentation as soon as 8.0 ships, because we're kinda heavily
21 matches
Mail list logo
