All that we basically need for PITR is to provide management code that lets old WAL segments get archived off to tape (or wherever) rather than deleted, plus some kind of control that lets the roll-forward process be stopped at the desired point-in-time rather than necessarily running to the end of the available WAL data. This isn't a trivial amount of code, but there's no great conceptual difficulty either.
Hope everybody realizes that the amount of WALs will get very big on active-update systems...
Of course they will be recycled in some point of time or other. And even if postgresql would provide PITR abilities, that would be nearly useless if WAL is recycled.. Its a space/time tradeoff issue..
Shridhar
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
