From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Garo Hussenjian <garo(at)xapnet(dot)com> |
Cc: | Postgresql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Idle transaction causing problems. |
Date: | 2003-02-18 23:49:11 |
Message-ID: | 4365.1045612151@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Garo Hussenjian <garo(at)xapnet(dot)com> writes:
> I have a server (pgsql 7.1.2) that periodically racks up a bunch of UPDATE
> waiting processes causing my php application to hang... I used gdb to get
> the debug_query_string on one of the UPDATE waiting processes and found it
> to be a very simple query on our session table... Not a server-breaker!
> The culprit seemed to be another process with status 'transaction idle' but
> the gdb debug_query_string was null (pointed to 0x0)... When I killed the
> transaction idle process the UPDATE waiting processes cleared out
> immediately and we were up and running again...
Sounds like it had an exclusive lock on the table the UPDATEs wanted to
update.
> Is there a way (w/ gdb or other) to determine the source of the idle
> transaction blocking traffic?
In 7.1 it's not at all easy to figure out. In 7.3 you can look in the
pg_locks system view to see whose lock is blocking whom.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-18 23:52:13 | Re: Configuring postmaster to use all available memory |
Previous Message | Steve Wolfe | 2003-02-18 23:48:44 | Re: Configuring postmaster to use all available memory |