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

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

"Wayne Conrad" <wconrad(at)yagni(dot)com> writes:
> "VACUUM FULL ANALYZE VERBOSE" on a "deadlocks" with other SQL statements.

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.

> To summarize the above output: there are three statements, each waiting on
> the other two:

No, you're reading it wrong. The sessions with granted=false are waiting
on the ones with granted=true.

It's conceivable that this actually is a deadlock situation, if the
connected clients are interrelated and are coded so that those other
queries must finish before they will do anything more. But you'll have
to break such a deadlock on the application side; Postgres has no way to
know what's happening.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Daniel Miller 2009-03-25 16:37:23 BUG #4733: Feature request: add plpy.query_plan(...) to plpythonu
Previous Message Tom Lane 2009-03-25 14:16:19 Re: BUG #4731: compile with -fast fails on ld: duplicate symbol _PGP_S2K_TYPE in pgp.o and pgp-mpi-openssl.o