Actually i thought of a solution for the wrap-around sometime back. Let me try to put my initial thoughts into it. May be it would get refined over conversation.
Transaction wrap-around failure Actually this problem is present 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 around failure. I think when we use a sub-transaction, the tuple would have xmin as the sub-transaction id(correct me, if i am wrong). If the tuple insertion becomes successful, we will make it equal to the parent transaction id. This way, we get a chance to re-use the sub-transaction id, previously used. This would mean accessing the tuple again after the sub-transaction completes 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 the tuple again and sub-freeze a tuple. If it gets un-successful, we rollback the sub-transaction. But for every un-successful transaction, we need a transaction id. May be in order to avoid this, we can have one transaction id to mark the failures and freeze all the failed rows for that transaction id. I am just throwing out an idea for consideration. Thanks, Gokul.
