Jason Tishler <Jason.Tishler@dothill.com> writes:
> I get the following backtrace for one of the hung psql processes:
> (gdb) bt
> #0 0x77f682cb in ?? ()
> #1 0x77f1cd76 in ?? ()
> #2 0x6103deee in _size_of_stack_reserve__ ()
> #3 0x6103d84e in _size_of_stack_reserve__ ()
> #4 0x67989978 in pqWait (forRead=0, forWrite=1, conn=0xa010258)
> at fe-misc.c:738
> #5 0x6798287c in connectDBComplete (conn=0xa010258) at fe-connect.c:1103
> #6 0x67981fb1 in PQsetdbLogin (pghost=0x0, pgport=0x0, pgoptions=0x0,
> pgtty=0x0, dbName=0x1a0260e8 "regression", login=0x0, pwd=0x0)
> at fe-connect.c:524
> #7 0x40e43f in main (argc=6, argv=0x1a021ad8) at startup.c:178
It would be helpful to see the contents of the conn object ("f 5" then
"p *conn" should do it).
If Hiroshi is correct that this is the *first* call to pqWait in
connectDBComplete, then I think we are looking at a kernel bug (or more
likely a cygwin bug). psql has opened a TCP connection socket and is
now waiting for the socket to show as write-ready before it will send
a connection request. If select() never reports the socket as
write-ready, you have a hang ... and it's not possible to blame the hang
on anything else but the kernel. Both ends of the connection are on the
same machine, so there's no network problem or anything like that.
There is not anything else that we should need to do at the application
level before we should be allowed to send data.
regards, tom lane
