Re: PITR logging control program

On Thu, 2004-04-29 at 20:24, Bruce Momjian wrote:
> I am willing to work on this...

There is much work still to be done to make PITR work..accepting all of
the many comments made.

If anybody wants this by 1 June, I think we'd better look sharp. My aim
has been to knock one of the URGENT items on the TODO list into touch,
however that was to be achieved.

The following work remains...from all that has been said...
- halt restore at particular condition (point in time, txnid etc)
- archive policy to control whether to halt database should archiving
fail and space run out (as Oracle, Db2 do), or not (as discussed)
- cope with restoring a stream of logs larger than the disk space on the
restoration target system
- integrate restore with tablespace code, to allow tablespace backups
- build XLogSpy mechanism to allow DBA to better know when to recover to
- extend logging mechanism to allow recovery time prediction
- publicise the API with BAR open source teams, to get feedback and to
encourage them to use the API to allow PostgreSQL support for their BAR
- use the API to build interfaces to the 100+ BAR products on the market
- performance tuning of xlogs, to ensure minimum xlog volume written
- performance tuning of recovery, to ensure wasted effort avoided
- allow archiver utility to be managed by postmaster
- write some good documentation
- comprehensive crash testing
- really comprehensive crash testing
- very comprehensive crash testing

It seems worth working on things in some kind of priority order.

I claim these, by the way, but many others look important and
interesting to me:
- halt restore at particular condition (point in time, txnid etc)
- cope with restoring a stream of logs larger than the disk space on the
restoration target system
- write some good documentation

Best Regards, Simon Riggs