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