Re: locking question - why is this not a deadlock?

From: peter royal <proyal(at)pace2020(dot)com>
To: Alvaro Herrera <alvherre(at)surnet(dot)cl>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: locking question - why is this not a deadlock?
Date: 2005-06-07 17:34:26
Message-ID: F0970EAE-0698-4C7A-8019-6881248B54D7@pace2020.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Jun 7, 2005, at 1:15 PM, Alvaro Herrera wrote:
> I don't think it's a bug, nor a deadlock situation. The problem is
> the
> "idle in transaction" server process, which holds some lock but isn't
> doing anything useful with it. Probably work would continue if the
> transaction was closed.
>
> This view is incomplete anyway, because you left out the xid column
> from
> the pg_locks view, which point out exactly to the locks that are
> blocking the other processes.
>
> I believe this problem wouldn't ocurr (or would be resolved in a
> different
> manner) in 8.1. I'm too lazy to replicate your scenario to check
> though ...

ah, thanks for the suggestion on what else to look for (first time
debugging something like this in postgresql). i'll be better prepared
to debug when it occurs again.

the 'idle in transaction' is a (mis) feature of the JDBC driver that
version of my software is using. (something that is fixed in the 8.0
JDBC driver thankfully, I'll likely start using that in the older
version of my sw to help alleviate this)

thanks again!
-pete

--
peter royal -> proyal(at)pace2020(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2005-06-07 17:42:47 Re: Issue with adding ORDER BY to EXCEPT.
Previous Message John Barham 2005-06-07 17:25:26 Possible to ignore transactions > n?