Re: BUG #4730: Vacuum full verbose analyze "deadlock" - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4730: Vacuum full verbose analyze "deadlock"
Date
Msg-id 24875.1237994924@sss.pgh.pa.us
Whole thread Raw
In response to BUG #4730: Vacuum full verbose analyze "deadlock"  ("Wayne Conrad" <wconrad@yagni.com>)
Responses Re: BUG #4730: Vacuum full verbose analyze "deadlock"  (Wayne Conrad <wconrad@yagni.com>)
List pgsql-bugs
"Wayne Conrad" <wconrad@yagni.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

pgsql-bugs by date:

Previous
From: Marko Kreen
Date:
Subject: Re: BUG #4731: compile with -fast fails on ld: duplicate symbol _PGP_S2K_TYPE in pgp.o and pgp-mpi-openssl.o
Next
From: "Daniel Miller"
Date:
Subject: BUG #4733: Feature request: add plpy.query_plan(...) to plpythonu