Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Good question. Imagine you have a serializable transaction like > > pg_dump, and then you have lots of newer transactions. If pg_dump is > > xid=12, and all the new transactions start at xid=30, any row created > > and expired between 12 and 30 can be removed because they are not > > visible. > > This reasoning is bogus. > > It would probably be safe for pg_dump because it's a read-only > operation, but it fails badly if the serializable transaction is trying > to do updates. An update needs to chase the chain of newer versions of > the row forward from the version that's visible to the xact's > serializable snapshot, to see if anyone has committed a newer version. > Your proposal would remove elements of that chain, thereby possibly > allowing the serializable xact to conclude it may update the tuple > when it should have given an error.
So in fact members of the chain are not visible, but vacuum doesn't have a strong enough lock to remove parts of the chain. What seems strange is that vacuum can trim the chain, but only if you do members starting from the head. I assume this is because you don't need to rejoin the chain around the expired tuples. ("bogus" seems a little strong.) -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq