Jason Wharton <jwharton@...> wrote:

>Oh, and another thing, it would be totally cool if you could start up a
>client transaction (read-only of course) that would allow you to query the
>database as-of a previous freeze point. Then, it would be a piece of cake

to

>dig in and figure out where Mr. Hacker did their thing... At least to the
>hour anyway...

Assuming that a sweep hasn't taken place since the point in time you want to
recreate, it should be possible to create a read only view of the database
as it was at a given point in time by only considering deltas up to a
particular transaction number. I don't think any major architectural
modification would be required, but I still haven't seen the source. Ann?
:-)

Are timestamps stored with transaction numbers? Ie: Can you find out what
the highest transaction number was at a given point in time?

I assume that blobs are released when their referencing row is swept, and so
would also be handled. Is this correct? I guess this also one of the
drawbacks of the architecture: No in place editing of a large objects makes
any change, no matter how minor, expensive.

Another feature which might be useful is point in time recovery from a
backup. The administrative sequence would then be: perform backup, run
sweep. Of course, the backup process would need to store the full history
of each row, not just the latest version. That would probably have major
implications for the implementation of gbak.

Just as an aside, I don't think these features are so useful for recovery
from hackers: After a successful attack, the whole thing is suspect anyway.
I do see that it would be very useful for recovery from wild applications.

Jan Mikkelsen
janm@...