Re: uninterruptable loop: concurrent delete in progress within table

Andres Freund <andres(at)2ndquadrant(dot)com> wrote:

> I do wonder if any of the other existing callers of HTSV are
> affected. I don't understand predicate.c well enough to be sure,
> but it looks to me like it'd could in theory lead to missed
> conflicts. Seems fairly unlikely to matter in practice though.

Early in the evaluation of the multi-xact bugs around 9.3 someone
pointed out that the serializable transactions could be affected. I
looked at it then, and it was very hard to set up a case to
actually hit that, and there were no field reports of it, so I
figured I should let the dust settle on fixes in this area before
deciding what to do.  It appeared that the fixes being made for
other reasons might fix this as well.  So far I haven't gotten the
feeling that this area has yet settled down enough to get back to
this.  Perhaps we've now gotten to that point?

Have we really pinned down the semantics of the the return values
for HeapTupleSatisfiesVacuum() at this point?  If so, I guess the
next question is, where is the exact meaning of each return value
documented?  The five to seven word comments in the enum value
declaration *seem* clear on the face of it, but I don't actually
have confidence what they really mean when, for example, a
subtransaction has rolled back.  It appears that
HEAPTUPLE_INSERT_IN_PROGRESS can be returned for a DELETE under
some circumstances, but it would take a lot of work to reverse-
engineer exactly what the various conditions that can cause that
return value are.  It seems like someone who knows what these
values really mean should capture that in a code comment somewhere.

What the code in predicate.c is using this for is to determine, for
a given tuple which the calling process is reading, whether it is
visible to the calling process but has been deleted by another
transaction (whose work this snapshot can't see), or is not visible
to the calling process and has been inserted by another transaction
(whose work this transaction can't see).  To qualify, the change
from the other transaction must be either committed or still
pending (i.e., it might commit).  With the tuple's visibility to
the current process known, what return values answer that question
without further checking, and what further checking is needed for
which other return codes?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company