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
|
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: