Re: PITR Recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PITR Recovery
Date: 2004-06-16 01:49:47
Message-ID: 15357.1087350587@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-06-16 01:59:49 Re: OWNER TO on all objects
Previous Message Bruce Momjian 2004-06-16 01:44:28 Re: pg_restore recovery from error.