ITAGAKI Takahiro wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> 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*.
Oh, but this should not be a problem, because a tuple is either frozen or removed completely -- xmax cannot precede xmin. > > > 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. Hmm. OK, I admit I have no idea how HOT works. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
