Andres Freund <andres@2ndquadrant.com> wrote:=0A=0A> I do wonder if any of =
the other existing callers of HTSV are=0A> affected. I don't understand pre=
dicate.c well enough to be sure,=0A> but it looks to me like it'd could in =
theory lead to missed=0A> conflicts. Seems fairly unlikely to matter in pra=
ctice though.=0A=0AEarly in the evaluation of the multi-xact bugs around 9.=
3 someone=0Apointed out that the serializable transactions could be affecte=
d. I=0Alooked at it then, and it was very hard to set up a case to=0Aactual=
ly hit that, and there were no field reports of it, so I=0Afigured I should=
let the dust settle on fixes in this area before=0Adeciding what to do.=A0=
It appeared that the fixes being made for=0Aother reasons might fix this a=
s well.=A0 So far I haven't gotten the=0Afeeling that this area has yet set=
tled down enough to get back to=0Athis.=A0 Perhaps we've now gotten to that=
point?=0A=0AHave we really pinned down the semantics of the the return val=
ues=0Afor HeapTupleSatisfiesVacuum() at this point?=A0 If so, I guess the=
=0Anext question is, where is the exact meaning of each return value=0Adocu=
mented?=A0 The five to seven word comments in the enum value=0Adeclaration =
*seem* clear on the face of it, but I don't actually=0Ahave confidence what=
they really mean when, for example, a=0Asubtransaction has rolled back.=A0=
It appears that=0AHEAPTUPLE_INSERT_IN_PROGRESS can be returned for a DELET=
E under=0Asome circumstances, but it would take a lot of work to reverse-=
=0Aengineer exactly what the various conditions that can cause that=0Aretur=
n value are.=A0 It seems like someone who knows what these=0Avalues really =
mean should capture that in a code comment somewhere.=0A=0AWhat the code in=
predicate.c is using this for is to determine, for=0Aa given tuple which t=
he calling process is reading, whether it is=0Avisible to the calling proce=
ss but has been deleted by another=0Atransaction (whose work this snapshot =
can't see), or is not visible=0Ato the calling process and has been inserte=
d by another transaction=0A(whose work this transaction can't see).=A0 To q=
ualify, the change=0Afrom the other transaction must be either committed or=
still=0Apending (i.e., it might commit).=A0 With the tuple's visibility to=
=0Athe current process known, what return values answer that question=0Awit=
hout further checking, and what further checking is needed for=0Awhich othe=
r return codes?=0A=0A--=0AKevin Grittner=0AEDB: http://www.enterprisedb.com=
=0AThe Enterprise PostgreSQL Company