Ivan,

>>* transaction A inserts row (e.g. 10), starts savepoint, and update that
>>row (e.g. to 20)
>>* transaction B now CAN insert value 10, because at this point there is
>>NO other
>> record version with value 10 (with one minor exception there is always
>> only one record version per transaction), so select in check
>> constraint will not
>> find anything, even if it can see all record versions

I think that the case of starting a savepoint is exactly when multiple record
versions are kept. I don't know that for a certainty, but if A rolls back to
the save point, it has to be able to recreate the state of the record before
the save point. I haven't traced the code, so I don't know that is the case.
My understanding is that the savepoint list carries record numbers around, not
values.


Regards,

Ann