Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
