Sorry, I didn't know what you needed. Here is the trace:
(gdb) bt
#0 0x2b04eef2 in select () from /lib/i686/libc.so.6
#1 0x2adeb06c in ?? () from /usr/X11R6/lib/libXt.so.6
#2 0x00000001 in ?? ()
#3 0x08136b88 in ?? ()
#4 0x2adc0c47 in XtChangeManagedSet () from /usr/X11R6/lib/libXt.so.6
#5 0x2adc13b0 in _XtWaitForSomething () from /usr/X11R6/lib/libXt.so.6
#6 0x2adc23f6 in XtAppNextEvent () from /usr/X11R6/lib/libXt.so.6
#7 0x2adb6a7c in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
#8 0x080b136a in main (argc=2, argv=0xbffff794) at main/main.c:252
Thanks for your help...
On Friday 25 February 2005 03:06 pm, Tom Lane saith:
> Terry Lee Tucker <terry@esc1.com> writes:
> >> Is this a bug? Did anybody look at the stack trace is sent? I don't
> >> have the expertise to analyze it.
>
> I haven't seen any stack trace. strace is not a stack trace --- I'm
> talking about attaching to the stuck process with gdb and getting the
> result of "bt".
>
> If it is hanging up in PQnotifies then that's certainly a bug, but you
> haven't proven that. The debug printouts you showed could equally well
> be interpreted as PQnotifies returned NULL and control went back to the
> idle loop. PQnotifies is not supposed to block, ever.
>
> At the moment I suspect the problem is somewhere upstream, probably in
> your interaction with the X toolkit. I think the program is blocking
> when in fact there are still bytes ready to be read by libpq.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)