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:
There's a "sysrqd" that apparently lets you use these features remotely,
but I've never tried it.
In response to
pgsql-bugs by date
|Next:||From: Craig Ringer||Date: 2011-12-20 23:59:51|
|Subject: Re: R: R: BUG #6342: libpq blocks forever in "poll" function|
|Previous:||From: Kevin Grittner||Date: 2011-12-20 22:02:46|
|Subject: Re: Security definer "generated column" function used in index|