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@xxxxxxxx> 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@xxxxxxxxxxxxxx) ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
