Bruce Momjian <[EMAIL PROTECTED]> writes: > The way combo cid is supposed to work is that you are deleting a row > created in your same transaction by a previous command id, so you look > in the combo cid array to see if a match for that pair exists --- if > not, you create a new entry and put the two cids on it.
> So, with the combo lock cid, you do the same process, and lookups of who > holds the lock looks at the cid combo, and if the second subtransaction > was aborted, the first one is the lock holder. If you again lock the > row, you create a new combo cid and use the original cid there because > the second cid was aborted. No, because no process other than the originator can see the combo-cid data structure, and for locking situations you really need other backends to be able to know whether the tuple is locked and how. But I think my proposal of extending MultiXact would fix it; please look at that. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match