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

From Bruce Momjian
Subject Re: Point in Time Recovery
Date
Msg-id 200407151457.i6FEvfi28321@candle.pha.pa.us
Whole thread Raw
In response to Re: Point in Time Recovery  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Point in Time Recovery  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> On Thu, 2004-07-15 at 03:02, Bruce Momjian wrote:
> > I talked to Tom on the phone today and and I think we have a procedure
> > for doing backup/restore in a fairly foolproof way.
> > 
> > As outlined below, we need to record the start/stop and checkpoint WAL
> > file names and offsets, and somehow pass those on to restore.  I think
> > any system that requires users to link those values together is going
> > to cause confusion and be error-prone.
> > 
> 
> Unfortunately, it seems clear that many of my posts have not been read,
> nor has anyone here actually tried to use the patch. Everybody's views
> on what constitutes error-prone might well differ then.
> 
> Speculation about additional requirements is just great, but please
> don't assume that I have infinite resources to apply to these problems.
> Documentation has still to be written.
> 
> For a long time now, I've been adding "one last feature" to what is
> there, but we're still no nearer to anybody inspecting the patch or
> committing it.

I totally understand your feeling this, and I would be feeling the exact
same way (but would probably have complained much earlier  :-)  ). 
Anyway, the problem is that Tom and I are serializing application of the
major features in the pipeline.  We decided to focus on nested
transactions (NT) first (it is a larger patch), and that is why PITR has
gotten so little attention from us.   However, there is no sense that
you had anything to do with it being places behind NT in the queue, and
therefore there is no feeling on our part that PITR is less important or
deserves less time than NT.  Certainly any system that made you less
likely to be applied would be unfair and something we will not do.

My explanation about the file format was an attempt to address the
method of passing the wal filename/offset to the recover process.  If
that isn't needed, I am sorry.

> There is building consensus on other threads that PITR should not even
> be included in the release (3 tentative votes). This latest request
> feels more like the necessary excuse to take the decision to pull PITR.
> I would much rather that we took the brave decision and pull it NOW,
> rather than have me work like crazy to chase this release.

Those three individuals are not representative of the group.  Sorry it
might seem there there is lack of enthusiasm for PITR, but it isn't true
from our end.  You might have noticed that the patch queue has shrunk
dramatically, and now we are focused on NT and PITR almost exclusively.

We will get there --- it just seems dark at this time.

--  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: Bruce Momjian
Date:
Subject: Re: How to display privileges in psql
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Release planning