Steve Clark <steve.cl...@netwolves.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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
