Alvaro Herrera <alvherre@commandprompt.com> wrote:
> > I think we might need additional "freezing-xmax" operations to avoid
> > XID-wraparound in the first path of vacuum, though it hardly occurs.
>
> I'm not sure I follow. Can you elaborate? Do you mean storing a
> separate relfrozenxmax for each table or something like that?
We need to work around wraparound of xmax in dead tuples. If we miss to
vacuum them and XID is wrapped, we cannot remove them until the next
XID-wraparound, because we treat them to be deleted in the *future*.
> > We just add XID of the vacuum to dead tuples we see in the
> > first path. When backends find a dead tuple and see the transaction
> > identified by XID in it has commited, they can freely reuse the area of
> > the dead tuple because we can assume index entries pointing the tuple
> > have been removed by the vacuum.
>
> I would be worried about leftover index entries being later used by new
> tuples in the heap. Then when you visit the index, find that entry, go
> to the heap and find the new tuple and return it, which could be bogus.
Avoiding dangling index entries, I'm thinking about reusing dead tuples
only if we see the VACUUM transaction have committed successfully.
That means the VACUUM transaction removed all index entries corresponding
those dead tuples; They are now Heap-Only-Tuples, so that we can recycle
them in the same manner as HOT updated tuples.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center