From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matt Mello <alien(at)spaceship(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: "deadlock detected" documentation |
Date: | 2003-05-16 19:13:48 |
Message-ID: | 28936.1053112428@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Matt Mello <alien(at)spaceship(dot)com> writes:
> The two situations I can think of are:
> 1) Two FK fields in a single row pointing to 2 different FK tables, for
> which any 2 updates get locks in opposite order (seems like a deadlock).
I don't think this is possible, at least in 7.3. All backends are
guaranteed to run the triggers of a given table in the same order,
so the foreign-row locks should be acquired in the same column order
in all cases.
> 2) Two FK fields pointing to only 1 FK table (both fields are references
> to the same table), for which each update gets independent locks instead
> of one lock for both fields, so there is a potential that #1 problem
> could impact this as well.
Not clear what you mean by "independent locks"; there is only one row
lock on a row.
The cases that I'd be concerned about are not within-row conflicts, but
multi-row conflicts...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-16 19:25:22 | Re: Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .." |
Previous Message | Randall Lucas | 2003-05-16 17:34:37 | Re: Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .." |