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 what you 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 and in 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:ring...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
