Re: BUG #4730: Vacuum full verbose analyze "deadlock"

From: Wayne Conrad <wconrad(at)yagni(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4730: Vacuum full verbose analyze "deadlock"
Date: 2009-03-25 18:05:08
Message-ID: 20090325180508.GL1185@yagni.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Mar 25, 2009 at 11:28:44AM -0400, Tom Lane wrote:
> What this looks like to me is an application problem. In each case
> you show, the only backends that actually *have* the lock are
> "<IDLE> in transaction", ie they are waiting for their clients to
> issue another command or close the transaction. The other queries
> won't be able to make any forward progress until those transactions
> complete and release their locks.

Tom,

Thank you. It's obvious now what a dunderhead I've been in misreading
the output of our own diagnostic tool. Thank you for the education.
We're going to sidestep the issue, for now, by going with Kevin's
suggestion to ditch the "FULL". If that doesn't work (such that I've
got to put the FULL back in and reintroduce the lockup), I'll get back
to my application, understand what's got it in knots, and untie it.

I apologize for blaming Postgres.

Best Regards,
Wayne Conrad

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2009-03-25 19:19:00 Re: BUG #4730: Vacuum full verbose analyze "deadlock"
Previous Message Thompson, Eric 2009-03-25 18:00:39 Re: BUG #4721: All sub-tables incorrectly included in search plan for partitioned table