Re: Proposal: Select ... AS OF Savepoint - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Proposal: Select ... AS OF Savepoint
Date
Msg-id 1194168145.4258.40.camel@ebony.site
Whole thread Raw
In response to Re: Proposal: Select ... AS OF Savepoint  (Hans-Juergen Schoenig <postgres@cybertec.at>)
Responses Re: Proposal: Select ... AS OF Savepoint  ("Gokulakannan Somasundaram" <gokul007@gmail.com>)
List pgsql-hackers
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.

Yeh, I'd want to do that for recovery purposes though, not for general
access.

The idea was to write a syncpoint every N seconds where we record the
time and a snapshot of what's in progress. 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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: xlogdump
Next
From: Bruce Momjian
Date:
Subject: Re: Segmentation fault using digest from pg_crypto