Re: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function - Mailing list pgsql-bugs

From Craig Ringer
Subject Re: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function
Date
Msg-id 4EF12097.5060907@ringerc.id.au
Whole thread Raw
In response to Re: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Security definer "generated column" function used in index
Next
From: Craig Ringer
Date:
Subject: Re: R: R: BUG #6342: libpq blocks forever in "poll" function