| 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: | Whole Thread | Raw Message | 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 |