| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | glue(at)pgexperts(dot)com |
| Cc: | Joel Jacobson <joel(at)gluefinance(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [Glue] Deadlock bug |
| Date: | 2010-08-20 18:28:50 |
| Message-ID: | 4C6EC962.4060908@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/20/10 7:18 AM, Tom Lane wrote:
> It does go through without any deadlock, *if* there is no foreign key
> involved. You didn't tell us exactly what the FK relationship is, but
> I suspect the reason for the deadlock is that one process is trying to
> update a row that references some row already updated by the other.
> That will require a row-level share lock on the referenced row, so you
> can get a deadlock.
That's correct. This is the generic example I was talking about earlier
on -hackers. I'm not certain it's a bug per spec; I wanted to talk
through with Kevin what we *should* be doing in this situation.
This is one example of a set of user-hostile FK-related deadlock
behavior we have. I'm just not certain it's logically possible to
improve it.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-08-20 18:30:02 | Re: git: uh-oh |
| Previous Message | Tom Lane | 2010-08-20 18:15:10 | Parallel pg_restore versus dependencies |