From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Steve Clark <steve(dot)clark(at)netwolves(dot)com> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: deadlock error - version 8.4 on CentOS 6 |
Date: | 2016-10-28 14:25:31 |
Message-ID: | 15432.1477664731@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Steve Clark <steve(dot)clark(at)netwolves(dot)com> writes:
> On 10/28/2016 09:48 AM, Tom Lane wrote:
>> Retrying might be a usable band-aid, but really this is an application
>> logic error. The code that is trying to do "lock table t_unit in
>> exclusive mode" must already hold some lower-level lock on t_unit, which
>> is blocking whatever the "update t_unit_status_log" command wants to do
>> with t_unit. Looks like a classic lock-strength-upgrade mistake to me.
> Oops - I forgot there is another process that runs every minute and
> takes about 1 second to run that does an exclusive lock on t_unit and
> t_unit_status_log.
The problem here doesn't seem to be that; it's that whatever transaction
is doing the "lock table" has *already* got a non-exclusive lock on
t_unit. That's just bad programming. Take the strongest lock you need
earliest in the transaction.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Geoff Winkless | 2016-10-28 14:31:58 | Re: WHERE ... IN condition and multiple columns in subquery |
Previous Message | Steve Clark | 2016-10-28 14:15:27 | Re: deadlock error - version 8.4 on CentOS 6 |