Re: PITR Recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PITR Recovery
Date
Msg-id 15357.1087350587@sss.pgh.pa.us
Whole thread Raw
In response to PITR Recovery  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: PITR Recovery  (Simon Riggs <simon@2ndquadrant.com>)
Re: PITR Recovery  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> -finalaction refers to what to do when target is reached - the purpose
> of this is to allow recovery of a database to occur when we don't have
> enough space for all of the xlogs at once, so we need to do recovery in
> batches.

It seems to me that this is the only *essential* feature out of what
you've listed, and the others are okay to add later.  So I question
your priorities:

> In time for beta freeze, I think it is possible to do a limited subset
> of the above:
> - implement DATABASE only (whole instance, not specific database)
> - implement END OF LOGS and TO TIMESTAMP
> - implement THEN START only
> - implement using simple C, rather than bison

which seem to include everything except the one absolute must-have
for any serious installation.

(BTW, I doubt that single-database recovery is possible at all, ever.
You can't go hacking the clog and shared tables and not keep all the
databases in sync.  So I'd forget the "object" concept altogether.)

> Implementation wise, I would expect all of this code to go in xlog.c,
> with the recovery target code living in ReadRecord().

I'd like to keep it out of there, as xlog.c is far too big and complex
already.  Not sure where else though.  Maybe we need to break down
xlog.c somehow.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_restore recovery from error.
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: OWNER TO on all objects