From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mario Weilguni <mweilguni(at)sime(dot)com> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Deadlock with ShareLocks? |
Date: | 2005-12-13 15:35:47 |
Message-ID: | 6550.1134488147@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mario Weilguni <mweilguni(at)sime(dot)com> writes:
> Version: 8.1
> Query : update last_modified set dataend=now() where type='list'
> DB-Error : ERROR: deadlock detected
> DETAIL: Process 10454 waits for ShareLock on transaction 1347632; blocked by
> process 15920.
> Process 15920 waits for ShareLock on transaction 1347633; blocked by process
> 10454.
> I thought ShareLock is not really blocking, or am I wrong?
You're wrong. This looks like a deadlock occasioned by trying to update
the same two rows in different orders in different transactions. In a
pre-8.1 release I'd have guessed that this might be a deadlock on
foreign key master rows, but in 8.1 that can't happen anymore.
If "WHERE type = 'list'" selects multiple rows, and someone else might
be trying to update more than one of those same rows using a different
WHERE clause, deadlock is definitely possible. You may not have much
choice but to take a table-level lock before starting the updates.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2005-12-13 15:45:14 | Re: Deadlock with ShareLocks? |
Previous Message | Tom Lane | 2005-12-13 15:29:50 | Re: Which qsort is used |