Alban Hertroys <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Alban Hertroys <[EMAIL PROTECTED]> writes:
>>> As they're inserts, and therefore not even touching the same data, I'm
>>> quite certain it's not some kind of row locking issue (does that even
>>> happen at all with MVCC?).
>>
>> I'm not. In particular this could be a foreign key locking issue ---
>> does the target table have foreign keys, and if so could inserts from
>> different transactions be referencing the same master row?
> It does have a reference to a table with statusses, but those are rather
> static. I suppose an integrity check is comparable to doing a select
> with respect to locking strategies? (Meaning that it wouldn't be the
> cause of my problem).
No, unfortunately it's more like a SELECT FOR UPDATE and it does take a
lock on the referenced row (with an eye to ensuring that the referenced
row can't go away before the new referencing row is committed).
I suspect this is indeed the cause of your problem.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
