Re: uninterruptable loop: concurrent delete in progress within table - Mailing list pgsql-bugs

Tom Lane <tgl@sss.pgh.pa.us> wrote:=0A> Kevin Grittner <kgrittn@ymail.com> =
writes:=0A>> Have we really pinned down the semantics of the the return val=
ues=0A>> for HeapTupleSatisfiesVacuum() at this point?=0A>=0A> Well, now th=
at Andres unilaterally redefined HEAPTUPLE_INSERT_IN_PROGRESS=0A> as meanin=
g whatever the heck was easiest, I'd say no ;-).=0A=0AThat's kinda what I w=
as afraid of.=0A=0A> But we have to=0A> think about what we do want from it=
.=A0 I'm not sure that we can positively=0A> guarantee to distinguish all t=
he possible states of an update-in-progress=0A> tuple from outside the upda=
ting backend, and it likely would not be worth=0A> the trouble to try since=
 the answer could change at any instant anyway.=0A=0AThat sounds like way m=
ore than SSI needs anyway.=0A=0A> For the statistical purposes I was on abo=
ut in the other thread, I would=0A> be satisfied if we could distinguish "w=
ill be live if all relevant=0A> transactions commit" from "will be dead if =
all relevant transactions=0A> commit".=0A=0AIf I'm understanding you, and i=
f HEAPTUPLE_LIVE and HEAPTUPLE_DEAD=0Aare clear-cut "nothing is in progress=
" cases, I think that might be=0Aenough.=A0 We know coming in whether the t=
uple is visible to our own=0Atransaction; the question is whether its exist=
ence has been or is=0Apotentially being changed by a top level transaction =
whose work we=0Acan't see.=A0 Ideally we would ignore the effects of a subt=
ransaction=0Aunderneath such a top level transaction if that subtransaction=
 has=0Arolled back, but it would only compromise efficiency (not=0Acorrectn=
ess) if we didn't ignore the work of subtransactions which=0Ahave already b=
een rolled back on an uncommitted top-level transaction.=0A=0A>> What the c=
ode in predicate.c is using this for is to determine, for=0A>> a given tupl=
e which the calling process is reading, whether it is=0A>> visible to the c=
alling process but has been deleted by another=0A>> transaction (whose work=
 this snapshot can't see), or is not visible=0A>> to the calling process an=
d has been inserted by another transaction=0A>> (whose work this transactio=
n can't see).=0A>=0A> I'm not sure why you'd need HeapTupleSatisfiesVacuum =
for that at all=0A> --- it sounds like a plain visible-according-to-query-s=
napshot test.=0A=0AThat is *one* of the things we need, and it is passed in=
 as a bool=0Aparameter.=A0 We also need to know whether another transaction=
 has=0Acommitted, or might commit, something which would delete a visible=
=0Atuple or insert a tuple which is not visible to us (but which has=0Abeen=
 read on a scan).=A0 In other words, would the results of this=0Ascan be di=
fferent if run again after commit of the other=0Atransaction?=A0 We're talk=
ing about the=0ACheckForSerializableConflictOut() function, in case my desc=
ription=0Ahere isn't clear; perhaps the function comments and/or code will=
=0Aclarify things.=0A=0Ahttp://git.postgresql.org/gitweb/?p=3Dpostgresql.gi=
t;a=3Dblob;f=3Dsrc/backend/storage/lmgr/predicate.c;h=3D7c8d53e6a5a44e8bbbd=
a453c730bb5073f8a3842;hb=3Dmaster#l3850=0A=0A> Certainly HTSV is unconcerne=
d with visibility as such, so it can't=0A> satisfy this requirement by itse=
lf.=0A=0ARight.=0A=0A--=0AKevin Grittner=0AEDB: http://www.enterprisedb.com=
=0AThe Enterprise PostgreSQL Company