I also have a client suffering an occasional 'application hang' running
Suse 11.2 and postgressql 8.4 on an 8 core box which is not reproducable
in a VMWare test environment.
Access to postgres is libpq 127.0.0.1 as well. Unfortunately the client
must restart ASAP and I have not produced a 'test case'.
On 12/20/2011 1:01 AM, Andrea Grassi wrote:
> Sorry if I insist, but now I have the case at hand (my test program is now blocked), so I can check and verify all
whatyou want.
> I would like to know if it can be a libpq bug or if you think the fault is due to a system bug or to a machine issue
andin this case I would be grateful if you could give me a hint on what could be.
>
> Regards, Andrea
>
> -----Messaggio originale-----
> Da: Craig Ringer [mailto:ringerc@ringerc.id.au]
> Inviato: sabato 17 dicembre 2011 7.19
> A: Andrea Grassi
> Cc: pgsql-bugs@postgresql.org
> Oggetto: Re: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
>
> On 16/12/2011 10:10 PM, Andrea Grassi wrote:
>> The client program and the postgres server are on the same host, client connects to 127.0.0.1.
>> In the meantime, my original program blocks (not my example but very probably the reasons are the same).
>>
>> I typed "ps -C testprogramname -o wchan:80=" and the output was only a single dash ( "-" ).
> That means it's not waiting in a kernel call right now. Was the program
> in the hung state you've observed at the time you ran the command? Its
> output would only be interesting when it's hung.
>> I searched for the complete stack in /proc/$pid/stack (where $pid) was the pid of my process but this file doesn't
exists!! Why ?
> Old kernel, maybe? You're running on some kind of enterprise-y distro,
> so who knows how ancient half the stuff in there is.
>
> --
> Craig Ringer
>
>