Re: [HACKERS] Update on PITR

>Bruce Momjian wrote
> Tom Lane wrote:
> > "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > > [ expecting to finish PITR by early June ]
> >
> > > Is this all still OK for 7.5? (My attempts at cataloguing
> changes has
> > > fallen by the wayside in concentrating on the more
> important task of
> > > PITR.) Do we have a planned freeze month yet?
> >
> > There's not really a plan at the moment, but I had June in
> the back of
> > my head as a good time; it looks to me like the Windows port will be
> > stable enough for beta in another month or two, and it'd be good if
> > PITR were ready to go by then.
> >
> > Is your timeline based on the assumption of doing all the
> work yourself?
> > If so, how about farming out some of it? I'd be willing to
> contribute
> > some effort to PITR. (It's been made clear to me that Red
> Hat really
> > wants PITR in 7.5 ;-))
>
> Agreed! Lets see if we can assemble a team to start coding PITR.
>

Thank you all for your offers of help. Yes, is the short answer; we
should be able to cut enough code on independent work streams to get
this system testable by end April.

As I say, I started coding some time back and am well into what I've
called Phase 1, so its probably best for me to complete that. You guys
will be contributing by looking at my code anyhow, so your goodwill is
certainly going to be called in, don't worry. There isn't anything too
hairy code wise anyhow, if I'm honest. For clarity, this will give the
facility to archive xlogs beyond their current short lifetime in the
recycling method currently used.

Phase 2 is definitely another matter...There doesn't seem to be any
dependency that I can see for that.... I called it Phase 2 because, yes,
I did make the assumption that I was doing it all myself, but I did set
off on this journey as a team effort and I welcome that still...
I described this piece of work earlier as:
Phase 2: add code to control recovery (to a point-in-time)
- will allow rollforward along extended archive history to point in
time, diskspace permitting

In my earlier summary of all design contributions there was the idea for
a postmaster command line switch which would make rollforward recovery
stop at the appropriate place. Two switches were discussed:
i) roll forward to point in time. This sounds relatively easy...recovery
is already there, all you have to do is stop it at the right place...but
I haven't looked into the exact mechanism of reading the xlog headers
etc.. [There's also a few bits of work to do there in terms of putting
in hooks for the command mechanism.
Something like postmaster -R "2004/12/10 19:37:04" as a loose example

ii) roll forward on all available logs, but shutdown at end, leaving pg
in a recovery-pending state (still). This then gives the DBA a chance to
do either a) switch in a new batch of xlogs, allowing an infinite
sequence of xlogs to be applied one batch at a time, or b) keep a "hot
standby" system continually primed and ready to startup should the
primary go down.

Neither of those looks too hard to me, so should be able to be done by
about mid-April when I'm thinking to have finished XLogArchive API. As I
say there's no particular dependency on the XLogArchive API stuff all
working, since they can both be tested independently, though we must put
them together for system testing.

Further tasks (what I had thought of as "Phase 3", but again these can
be started now...)
- what to do should a cancel CTRL-C be issued during recovery..what
state is the database left in?
- How do you say "this is taking to long, I really need my database up
now, whatever state its in" (when recovery is grinding away, not before
you start it or after it has failed, which is where you would use
pg_resetxlog)....
- can you change your mind on that once its up and you see what a mess
its in! i.e. put it back into recovery? what would that take - saving
clogs? an optional "trial recovery" mode?
- how would we monitor a lengthy recovery? watch for "starting recovery
of log XXX" messages and do some math to work out the finish time, or is
there a better way?
- is it possible to have parallel recovery processes active
simultaneously for faster recovery?? can we work anything into the
design now that would allow that to be added later?

What I think is really important is a very well coordinated test plan.
Perhaps even more importantly a test plan not written by me, since I
might make some dangerous assumptions in writing it. Having a written
test plan would allow us to cover all the edge cases that PITR is
designed to recover from. It will be pretty hard for most production
users of PostgreSQL to fully test PITR, though of course many will "kick
the tyres" shall we say, to confirm a full implementation. Many of the
tests are not easily automatable, so we can't just dream up some more
regression tests. A written plan would then allow coordinated testing to
occur across platforms, so a QNX user may spot something that also
effects Solaris etc.. Is that anything any large open source outfit
(commercial or non-commerical) would be able to contribute the time of a
test analyst for 10 days to complete? ;) ...I didn't get a huge response
from the community when last I requested assistance in that area,
assuming my post got through.

Overall, I'm confident that we're getting close to this becoming fully
real. The main issues historically were that the xlogs didn't contain
all that was required for full recovery, but those challenges have been
solved already by J.R. and Patrick(subject to full system testing).

Best Regards,

Simon Riggs
2nd Quadrant