"Dirschel, Steve" <steve.dirschel@xxxxxxxxxxxxxxxxxx> writes: > Above I can see PID 3740 is blocking PID 3707. The PK on table > wln_mart.ee_fact is ee_fact_id. I assume PID 3740 has updated a row > (but not committed it yet) that PID 3707 is also trying to update. Hmm. We can see that 3707 is waiting for 3740 to commit, because it's trying to take ShareLock on 3740's transactionid: > transactionid | | | | | | 251189986 | | | | 54/196626 | 3707 | ShareLock | f | f | 2023-10-31 14:40:21.837507-05 251189986 is indeed 3740's, because it has ExclusiveLock on that: > transactionid | | | | | | 251189986 | | | | 60/259887 | 3740 | ExclusiveLock | t | f | There are many reasons why one xact might be waiting on another to commit, not only that they tried to update the same tuple. However, in this case I suspect that that is the problem, because we can also see that 3707 has an exclusive tuple-level lock: > tuple | 91999 | 93050 | 0 | 1 | | | | | | 54/196626 | 3707 | ExclusiveLock | t | f | That kind of lock would only be held while queueing to modify a tuple. (Basically, it establishes that 3707 is next in line, in case some other transaction comes along and also wants to modify the same tuple.) It should be released as soon as the tuple update is made, so 3707 is definitely stuck waiting to modify a tuple, and AFAICS it must be stuck because of 3740's uncommitted earlier update. > But I am being told those 2 sessions should not be trying to process the > same PK rows. Perhaps "should not" is wrong. Or it could be some indirect update (caused by a foreign key with CASCADE, or the like). You have here the relation OID (try "SELECT 93050::regclass" to decode it) and the tuple ID, so it should work to do SELECT * FROM that_table WHERE ctid = '(0,1)'; to see the previous state of the problematic tuple. Might help to decipher the problem. regards, tom lane
