Actually i thought of a solution for the wrap-around sometime back. Let me try to put my initial thoughts into it. May
beit would get refined over conversation.<br /><br />Transaction wrap-around failure <br /><br />Actually this problem
ispresent even in today's transaction id scenario and the only way we avoid is by using freezing. Can we use a similar
approach?This freezing should mean that we are freezing the sub-transaction in order to avoid the sub-transaction wrap
aroundfailure. I think when we use a sub-transaction, the tuple would have xmin as the sub-transaction id(correct me,
ifi am wrong). If the tuple insertion becomes successful, we will make it equal to the parent transaction id. This way,
weget a chance to re-use the sub-transaction id, previously used. This would mean accessing the tuple again after the
sub-transactioncompletes<br /><br />On the recovery front, the freezing should get logged into redo. With this
approach,we need only one sub-transaction id for the entire copy. If insert gets successful for a copied row, we goto
thetuple again and sub-freeze a tuple. If it gets un-successful, we rollback the sub-transaction. But for every
un-successfultransaction, we need a transaction id. May be in order to avoid this, we can have one transaction id to
markthe failures and freeze all the failed rows for that transaction id.<br /><br />I am just throwing out an idea for
consideration.<br/><br />Thanks,<br />Gokul.<br />
