Re: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function

On 21/12/2011 1:42 AM, Tom Lane wrote:
> 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.
>
I've been leaning that way too; that's why I was asking him for
/proc/$pid/stack and `wchan -C programname -o wchan:80=` output - to get
some idea of what function in the kernel it's sitting in.

Unfortunately the OP is on some enterprise distro that doesn't have
/proc/$pid/stack . wchan info would still be useful. I wonder how old
their kernel is? The bug could've already been fixed. /proc/pid/stack
has been around since 2008 so it must be pretty elderly.

OP: You can also get a kernel stack for a process by enabling the magic
SysRQ key (see Google) then using Alt-SysRq-T . This requires a physical
keyboard directly connected to the server. It emits the stack
information via dmesg. See:

http://en.wikipedia.org/wiki/Magic_SysRq_key

There's a "sysrqd" that apparently lets you use these features remotely,
but I've never tried it.

--
Craig Ringer