Clarence Gardner <clarence@xxxxxxxxxx> writes: > The difference I'm asking about is that my artificial ones always involve > waiting on a transaction, while the ones from the real application always > involve one transaction wait and one tuple wait. > The first question is, is there any significance to this difference? Yup. > If so, the second question is, what is it? :) In looking at some code in > heapam.c, I see the following comment that sorta kinda sounds like maybe > there are three parties involved, with two of them waiting on a locked > tuple? Got it in one. The guy waiting on the tuple-specific lock is second in line to actually mung the tuple. Whoever is first in line behind the current tenant will be blocked trying to acquire ShareLock on the current tenant's transaction ID. What you appear to have is a situation where two transactions are trying to lock or update the same two rows in different orders. Without a lot more info about your application logic, I couldn't guess why this seems to be associated with having more than two transaction interested in the same tuple. Note that the guy looking for ShareLock on the tuple is evidently either doing SELECT FOR SHARE on this tuple, or trying to install a new tuple referencing this one as a foreign key (which does SELECT FOR SHARE under the hood). But he's blocked by someone who's done either SELECT FOR UPDATE or an actual UPDATE on that tuple. regards, tom lane
