Bruce Momjian wrote:
> Just to summarize:
>
> o Every tuple gets a heap ctid
> o Only the root tuple gets an index entry
> o We can easily remove dead tuples that aren't the root because
> by definition, nothing points to them, including backends and
> indexes
I am still wondering about the "easily" here. Basically this
needs some kind of wal entry to be crash safe.
Else some later tx might reuse the slot:- some update on page produces page image in wal- slot removed- slot reused and
comitted-page not written- crash- wal fullpage restores the page to the version before slot
removed(- would need a wal replay for slot removed from hot chain here)- wal restores slot reuse, but the slot is now
partof a wrong
hot chain and the chain is broken (unless we have the above step)
Do we have this wal entry ?
> The problem is that a dead root tuple has to stay around
> because while no backends can see it, the index does. We
> could move a live tuple into root ctid slot, but if we do
> that, the live tuple changes its ctid while it is visible.
>
> Could we insert index tuples for the live tuple and then
> remove the root tuple, perhaps later? So basically we break
> the chain at that time.
> The problem there is that we basically have nothing better
> than what we have now --- we are just delaying the index
> insert, and I don't see what that buys us.
yes, not really promising.
> Could a _new_ tuple take over the root tuple slot? It is
> new, so it doesn't have a ctid yet to change. I think that
> means the index walking
> could go forward or backward, but on the same page. To illustrate,
> with ctid slot numbers:
>
> [1] root INSERT
> [2]
> [3]
>
> [1] root INSERT
> [2] UPDATE
> [3]
>
> [1] root INSERT (dead)
> [2] UPDATE 1
> [3]
>
> [1] root UPDATE 2
> [2] UPDATE 1
> [3]
Imho no, because that would need a back pointer in [1] to [2] so that
readers arriving at [1] (e.g. through index) can see [2] until [1] is
visible.
I think we don't want backpointers. (rather go the tuple swapping route)
Andreas
