Re: New feature request: FlashBack Query
От | Florian G. Pflug |
---|---|
Тема | Re: New feature request: FlashBack Query |
Дата | |
Msg-id | 45DC50B3.3040809@phlo.org обсуждение исходный текст |
Ответ на | Re: New feature request: FlashBack Query (Theo Schlossnagle <jesus@omniti.com>) |
Ответы |
Re: New feature request: FlashBack Query
|
Список | pgsql-hackers |
Theo Schlossnagle wrote: > > On Feb 20, 2007, at 1:40 PM, Tom Lane wrote: > >> RPK <rohitprakash123@indiatimes.com> writes: >>> I did not mean asking for undo from a life-time log. Since FlashBack >>> Technology is already there, I just mean that world's most advanced >>> database >>> (PostgreSQL, as they say), must have an optimized way for undoing of at >>> least a week changes. >> >> You're living in a dream world. Do you know any Oracle DBs who keep >> enough rollback segments to go back a week? > > Ours go for a good 6 hours sometimes :-D Eeven if it's just one hour, it's certainly better than nothing. I fully agree that I'd not be acceptable to introduce performance problems for _everyone_ by introducing flashback. But if you only experience a drop in performance if you actually enable flashback (by, let's say setting vacuum_min_deadtime=1h), then I don't see why anyone would object to having support for some kind of flashback. However, I just realized that doing this is much harder than I initially thought, because catalog access always happens with SnapshotNow, and e.g. "drop table" deletes datafiles at commit time, and not during vacuum. Supporting "begin; drop table mytable; commit; begin; set transaction flashback 1 hour; select * from mytable; commit" would therefore be really hard... greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: