Re: Proposal: Select ... AS OF Savepoint

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Proposal: Select ... AS OF Savepoint
Дата
Msg-id 1194168145.4258.40.camel@ebony.site
обсуждение исходный текст
Ответ на Re: Proposal: Select ... AS OF Savepoint  (Hans-Juergen Schoenig <postgres@cybertec.at>)
Ответы Re: Proposal: Select ... AS OF Savepoint  ("Gokulakannan Somasundaram" <gokul007@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: xlogdump
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Segmentation fault using digest from pg_crypto