Decibel! wrote: > On Jul 30, 2007, at 8:00 PM, Alvaro Herrera wrote: >> 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. > > What if it's frozen, then deleted, and then we wrap on xmax? Wouldn't that > make the tuple re-appear?
That cannot happen, because the next vacuum will remove the tuple if the Xmax is committed. If the deleting transaction aborts, then vacuum will set Xmax to Invalid (see heap_freeze_tuple in heapam.c). One potential problem you would see is if the deleting transaction marks it deleted and then not commit for 2 billion transactions, thus vacuum is not able to remove it because it shows up as delete-in-progress. However there are plenty other problems you would hit in that case (autovacuum starting to misbehave being the first you would probably notice). -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
