> > (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?
>
> Well, that particular backend is not hung: the stack trace proves it's
> waiting for a command from its frontend. Perhaps you need to look
> through your other Postgres processes.
Sorry, hang is the wrong word. Block is more correct. I know it's
waiting for commands from the front end, but I'm trying to figure out
what front end/query/lib/page is causing the problem. It's only once
in few thousand queries that it happens and I'm going crazy trying to
figure out what it is that's causing this. I've set
stats_command_string to true and attached gdb to the backend, but
that's null. Is there another var in the backend that contains a
pointer to the last query performed? I haven't found it if there
is... -sc
--
Sean Chittenden
