On 11/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-11-02 at 13:40 +0100, Hans-Juergen Schoenig wrote: > > > > > > I think Simon Riggs is already working on that idea. This one is > > > fairly easy to implement. I think these are some of the features > > > only a time-stamp based database can implement. I think database > > > standards were formed during the time, when the data consistency was > > > provided with Lock based mechanisms. And moreover i have already > > > committed on the indexes with snapshot and i am still waiting for > > > its approval from hackers. If that does go through, then i need to > > > work on the reverse mapping hash tables, which is really a long > > > task. So i may not be able to take up time-travel now. > > > > > > > > > > > > > if i remember my last talk with Simon correctly the idea is to have > > timetravel across transactions. > > having this feature inside a transaction will not make it into CVS as > > it is basically of no practical use. > > i would suggest to put some effort into making it work across > > transactions. just saving the snapshot is not enough > > here - there are a couple of other things which have to be taken into > > consideration (transaction wraparound, etc.) > > > > > > if you want to work on timetravel my team and i can provide some > > assistance as we wanted to help in this area anyway.
Thanks for your inputs Simon. Yeh, I'd want to do that for recovery purposes though, not for general > access. I guessed it. The idea was to write a syncpoint every N seconds where we record the > time and a snapshot of what's in progress. What exactly is getting recorded here? Will the Syncpoint be similar to the Undo Log at distinct intervals? This may be a stupid question. But is it not a good idea to implement time-travel through the Replication server. The syncpoints would need to > be visible in the system like prepared transactions. A superuser could > reconnect to one of the syncpoints and see data as it was at the > previous time. Difficulties being dropped objects and the negative > effects on vacuuming, both of which are surmountable, but are big > current blockers. > > I'm not working on this currently, maybe an 8.5+ feature. > > -- > Simon Riggs > 2ndQuadrant http://www.2ndQuadrant.com > > -- Thanks, Gokul. CertoSQL Project, Allied Solution Group. (www.alliedgroups.com)