Tom Lane wrote:
"Simon Riggs" <simon@2ndquadrant.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.

--
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, Pennsylvania 19073

Search Discussions

  • Simon Riggs at Mar 31, 2004 at 8:32 pm

    Bruce Momjian wrote
    Tom Lane wrote:
    "Simon Riggs" <simon@2ndquadrant.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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers-pitr @
categoriespostgresql
postedMar 31, '04 at 6:26p
activeMar 31, '04 at 8:32p
posts2
users2
websitepostgresql.org
irc#postgresql

2 users in discussion

Bruce Momjian: 1 post Simon Riggs: 1 post

People

Translate

site design / logo © 2021 Grokbase