[ZODB-Dev] Savepoints are invalidated once they are used

[Tim Peters]

[Jeremy Hylton]
>> IIRC, the old implementation of savepoints kept a copy of the index at
>> the time the savepoint was taken so that you could rollback to it
>> multiple times.  I don't think there's any way to avoid such a copy.

[Dieter Maurer]
> Maybe, we keep the original implementation (a savepoint restore deletes
> this savepoint) and update the docstring?
>
> It is rare that we need to keep the savepoint.

All implementations (the current one in SVN, "the old" one, and "the
original" one) copy the index at the time a savepoint is made, but for more
reasons than Jeremy gave (I suspect his memory of the old implementation's
details has faded a bit ;-)).  To be usable for rollback at all (even once),
a savepoint has to remember the state of the TmpStore index at the time the
savepoint is made -- otherwise it couldn't restore the index to that state
on a rollback.  If the savepoint shares its remembered index object with
TmpStore, then mutations to the latter's index effectively corrupt the
savepoint's remembered index.

The additional copying recently added, to support rolling back to a
savepoint multiple times, occurs only when a rollback is actually performed.
I don't mind that expense at all.

BTW, I don't expect we can know what's rare or not with these yet.  Nesting
is a powerful ability subtransactions couldn't approach, so it's plausible
to imagine that savepoints will get used for much more than just their
RAM-freeing side effects -- and most copying here is to support nesting
correctly.
 
> If we do, we can (usually) create a one with the state after the
> "restore".

Sorry, I couldn't follow that sentence.

I would like to do less indexing copying when a savepoint is made, but don't
see an obvious and effective way to get away with that.  The current
implementation has become "obviously correct" instead of "not obviously
wrong", and that's a good place to leave it for now in the absence of dire
need.