On Thu, Aug 18, 2005 at 03:48:55PM -0400, Tom Lane wrote:
> The only solution I can see (short of abandoning lazy VACUUM) is that
> we have to make the code that follows t_ctid chains more wary. That
> code is already aware (at least in the places I looked at) that a t_ctid
> link might lead to an empty slot, but if there is a tuple in the slot
> it just assumes that that is really a descendant version of the tuple
> pointing to it. That won't do. But I believe it would work if we also
> test that the XMIN of the tuple in the slot equals the XMAX of the
> referencing tuple. If they are unequal, we can conclude that the
> original child tuple is dead and has been removed, so there is no
> current version of the referencing tuple.
Interesting failure mode. While reading it I was suddenly struck by the
thought that overwriting storage managers may somehow be more resistent
to these kind of failures. This may well be true, because there is
never need for a VACUUM process which would fail to correctly determine
whether a tuple is truly dead or not; but in the end, concurrent
processes have to follow t_ctid chains anyway.
I also considered whether the correct test was xmin=xmax, or rather a
transaction-tree test was needed. Then I realized that it's not
possible for a transaction to create a tuple chain crossing a
subtransaction boundary. So the xmin=xmax test is correct. I assume
you will make a note on this somewhere, just in case we forget later.
> This is going to require a number of changes since there are several
> places that follow t_ctid chains.
I wonder whether this should be refactored so all of them use a single
piece of code.
--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
La Feria de las Tinieblas, R. Bradbury)