Re: POC: Cleaning up orphaned files using undo logs

On Mon, Sep 16, 2019 at 10:37 PM Robert Haas <robertmhaas(at)gmail(dot)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