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
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 |