From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | <pgsql-bugs(at)postgresql(dot)org>,<tmoore(at)ttitech(dot)net> |
Subject: | Re: TRUNCATE HANGS |
Date: | 2010-12-04 18:43:54 |
Message-ID: | 4CFA378A02000025000382B0@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
tmoore wrote:
> Running this test, a deadlock can be created without fail.
You haven't shown any evidence of a deadlock -- just blocking.
That's not at all the same thing.
> postgres 16990 26837 44 11:20 ? 00:28:51 postgres: postgres uisdb
> 127.0.0.1(34405) idle in transaction
> postgres 16993 26837 0 11:20 ? 00:00:00 postgres: postgres
> uisdb [local] idle
> When I kill the 'idle' process, things unblock
Are you sure it isn't the "idle in transaction" one that matters?
What happens if you just COMMIT it?
> I'm at loss for what is the underlying cause of this problem.
You should be able to tell from pg_locks which transaction is
blocking what.
This doesn't look like a bug. If you still have problems solving
this, you should probably start a new thread on pgsql-general or
pgsql-novice. If you can create a small self-contained test case,
which starts with creating and populating tables, so that others can
reproduce your issue, you'll be able to get more specific help.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | tmoore | 2010-12-04 19:26:54 | Re: TRUNCATE HANGS |
Previous Message | tmoore | 2010-12-04 17:41:53 | TRUNCATE HANGS |