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

To try to solve this problem my colleague (the systems engineer that takes
care of the machine) did:
1. Disable drivers HP : NOT SOLVED
2. Disable Hyperthreading: NOT SOLVED
3. Reduced the phisical CPU (enabled on boot) from 32  to 16: THIS SOLVED
THE PROBLEM.

Now 2 weeks passed without blocking and the problem seems temporary solved.
We have made an accurate test on the hardware but it's seems to be ok.

It's seems to be a kernel bug, so I posted the problem to Novell support.
Thanks for the help. Regards=20

Andrea Grassi
=20
-----Messaggio originale-----
Da: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Inviato: mercoled=EC 21 dicembre 2011 17.01
A: Andrea Grassi
Cc: 'Craig Ringer'; harrywr2@comcast.net; 'Pg Bugs'; 'Alvaro Herrera'
Oggetto: Re: R: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll"
function=20

"Andrea Grassi" <andreagrassi@sogeasoft.com> writes:
> In internet I searched for detailed specifications of poll/select system
> functions but I didn't understand one thing, that is which one of the 2
> statement is true:
> 1) poll/select wait only for FUTURE modifications of ready-read state of
> sockets
> 2) poll/select check if there is something to read at the moment of the
call
> and otherwise wait for FUTURE modifications of ready-read state

#1 is nonsense.  If poll worked like that, it would be impossible for
anyone to use it without suffering from race conditions.  But if you
don't see where exactly the poll() specification says so, I observe
that it says first that poll sets the bit(s) if the requested condition
is true, and second that *if* none of the events have occurred yet,
poll should wait.  See for instance
http://pubs.opengroup.org/onlinepubs/007908799/xsh/poll.html

            regards, tom lane