Re: Lock problem

From: "Victor Sterpu" <victor(at)caido(dot)ro>
To:
Cc: "PostgreSQL General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Lock problem
Date: 2014-04-02 15:59:45
Message-ID: em02a9d305-ad63-406f-bade-295b0aa173e4@victor-pc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

------ Original Message ------
From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Victor Sterpu" <victor(at)caido(dot)ro>
Cc: "PostgreSQL General" <pgsql-general(at)postgresql(dot)org>
Sent: 4/2/2014 6:49:28 PM
Subject: Re: [GENERAL] Lock problem

>On Wed, Apr 2, 2014 at 10:19 AM, Victor Sterpu <victor(at)caido(dot)ro> wrote:
>>
>> Hello
>>
>> I have a problem that it seems to be very hard to debug.
>> Problem is from some postgresql locks. I use PostgreSQL 9.1.8.
>>
>> I runned this query to fid the locks:
>>
>> SELECT bl.pid AS blocked_pid,
>> a.usename AS blocked_user,
>> kl.pid AS blocking_pid,
>> ka.usename AS blocking_user,
>> a.current_query AS blocked_statement
>> FROM pg_catalog.pg_locks bl
>> JOIN pg_catalog.pg_stat_activity a ON a.procpid = bl.pid
>> JOIN pg_catalog.pg_locks kl ON kl.transactionid = bl.transactionid
>>AND kl.pid != bl.pid
>> JOIN pg_catalog.pg_stat_activity ka ON ka.procpid = kl.pid
>> WHERENOT bl.granted;
>>
>> The result is a recursive lock.
>> Pid 10665 is blocked by pid 9844 and pid 9844 is blocked by 10665.
>> These 2 inserts are in 2 separate transactions.
>> Can this be a postgresql bug?
>>
>> blocked_pid blocked_user blocking_statement blocking_duration
>>blocking_pid blocking_user blocked_statement blocked_duration
>
>> 10665 postgres <IDLE> in transaction
>
>"<IDLE> in transaction" is a locking red flag. It means your
>application has opened a transaction and is sitting there holding the
>transaction open. This is a very common cause of subtle application
>locking bugs. It can be legit if the application is doing heavy
>processing during a transaction or you simply raced to an idle
>transaction in pg_stat_activity, but in my experience 95%+ of the time
>it means transaction leakage which in turn leads to locking problems.
>
>merlin

This is weird because all of my transaction have commit or rollback. I
don't leave unterminated transactions.
I can't see how this is happening.
Is there a possibility that some network problems generate this problem?
If this is the case is these some server protection for this situation?

But why a unterminated transaction blocks all table operations?

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Victor Sterpu 2014-04-02 16:00:09 Re: Lock problem
Previous Message Merlin Moncure 2014-04-02 15:49:28 Re: Lock problem