| 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: | Whole Thread | Raw Message | 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 |