Terry Lee Tucker <terry@xxxxxxxx> writes:
> 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
Well, indeed it is not stuck in PQnotifies --- it's waiting for input,
and evidently not seeing any.
Looking back at your strace, the first line shows that the connection to
the PG server is on FD 3, since that's recognizably a NOTIFY message:
recv(3, "A\0\0\0\25\0\0~3move_update\0\0C\0\0\0\rUPDAT"..., 16384, 0) = 42
I suppose that the traffic on FD 4 is going to and from the X server.
What seems odd is that some of the select()s are waiting on both FD 3
and FD 4, but some on only one or the other. I'd have expected all of
them to wait on both.
I think what is happening is that the X toolkit is failing to wait on
FD 3 at the critical point, presumably because it thinks you are no
longer interested in input from that FD. It's been a very long time
since I touched low-level X stuff, but perhaps you need to remind the
toolkit repeatedly that you are interested in FD 3? Is there any path
of control that could cancel the callback assignment for DbInputCB?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
