| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Andrea Grassi" <andreagrassi(at)sogeasoft(dot)com> |
| Cc: | harrywr2(at)comcast(dot)net, "'Craig Ringer'" <ringerc(at)ringerc(dot)id(dot)au>, "'Pg Bugs'" <pgsql-bugs(at)postgresql(dot)org>, "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com> |
| Subject: | Re: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function |
| Date: | 2011-12-20 17:42:26 |
| Message-ID: | 6410.1324402946@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"Andrea Grassi" <andreagrassi(at)sogeasoft(dot)com> writes:
> This is the server side stack kept by gdb:
> [ server is waiting to receive something from client ]
> The netstat command on client and server connection has this output:
> The first line should be the server, the second the client.
> Proto Recv-Q Send-Q Local Address Foreign Address State
> PID/Program name
> tcp 0 0 127.0.0.1:5432 127.0.0.1:53129
> ESTABLISHED -
> tcp 48 0 127.0.0.1:53129 127.0.0.1:5432
> ESTABLISHED 29802/g_mrprun.e
Hrm. What's with the 48 bytes in the client's receive queue? Surely
the kernel should be reporting that the socket is read-ready, if it's
got some data. I think you've found an obscure kernel bug ---- somehow
it's failing to wake the poll() caller.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2011-12-20 17:50:37 | Incorrect comment in heapam.c |
| Previous Message | Andrea Grassi | 2011-12-20 17:28:31 | R: R: R: R: BUG #6342: libpq blocks forever in "poll" function |