> > I can already identify that. Using the PID of the backend +
> > sockstat on both the DB server and on the remote www server I can
> > get the PID of the webserver process causing the problem, but I
> > have no clue which customer, which page, which query, etc. The
> > www process is doing something along the lines of:
>
> > BEGIN;
> > SELECT....
> > [waits forever]
> > END;
>
> Oh, you want to know the actual current query. Turn on
> stats_command_string or whatever it's called. See the statistics
> collector documentation.
>
> If this is after-the-fact (ie, you want to know about a process
> that's hung right now), attach to it with a debugger and print out
> debug_query_string.
Alright, turned on stats_command_string and am seeing nothing in any
of the stats tables and debug_query_string is null.
(gdb) p debug_query_string
$1 = 0
(gdb) bt
#0 0x283d0c58 in recvfrom () from /usr/lib/libc.so.4
#1 0x283c092b in recv () from /usr/lib/libc.so.4
#2 0x80f11c6 in secure_read ()
#3 0x80f4557 in StreamConnection ()
#4 0x80f4935 in pq_getbyte ()
#5 0x81377b0 in PostgresMain ()
#6 0x811a63c in PostmasterMain ()
#7 0x8119e5b in PostmasterMain ()
#8 0x811934b in PostmasterMain ()
#9 0x8118e94 in PostmasterMain ()
#10 0x80f53d7 in main ()
#11 0x8069b3e in _start ()
Any ideas on how I can figure out what the mystery query/app/lib is
that's causing my backend to hang with a zillion connections that are
all idle?
-sc
--
Sean Chittenden
