From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alban Hertroys <alban(at)magproductions(dot)nl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Transaction size |
Date: | 2005-01-10 13:30:26 |
Message-ID: | 11099.1105363826@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alban Hertroys <alban(at)magproductions(dot)nl> writes:
> Tom Lane wrote:
>> Alban Hertroys <alban(at)magproductions(dot)nl> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-01-10 13:39:50 | Re: ORDER BY in UNION query |
Previous Message | John Sidney-Woollett | 2005-01-10 13:10:42 | Re: ORDER BY in UNION query |