On Mon, Sep 16, 2019 at 10:37 PM Robert Haas <robertmh...@gmail.com> wrote: > > It seems to me that zheap went wrong in ending up with separate undo > types for in-place and non-in-place updates. Why not just have ONE > kind of undo record that describes an update, and allow that update to > have either one TID or two TIDs depending on which kind of update it > is? There may be a reason, but I don't know what it is, unless it's > just that the UnpackedUndoRecord idea that I invented wasn't flexible > enough and nobody thought of generalizing it. Curious to hear your > thoughts on this. >
I think not only TID's, but we also need to two uur_prevundo (previous undo of the block) pointers. This is required both when we have to perform page-wise undo and chain traversal during visibility checks. So, we can keep a combination of TID and prevundo. The other thing is that during rollback when we collect the undo for each page, applying the action for this undo need some thoughts. For example, we can't apply the undo to rollback both Insert and non-inplace-update as both are on different pages. The reason is that the page where non-inplace-update has happened might have more undos that need to be applied before this. We can somehow make this undo available to apply while collecting undo for both the heap pages. I think there is also a need to identify which TID is for Insert and which is for non-inplace-update part of the operation because we won't know that while applying undo unless we check the state of a tuple on the page. So, with this idea, we will make one undo record part of multiple chains which might need some consideration at different places like above. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
