Re: deadlock error - version 8.4 on CentOS 6

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

In response to

Browse pgsql-general by date

  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