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 Andrea Grassi -----Messaggio originale----- Da: Tom Lane [mailto:t...@sss.pgh.pa.us] Inviato: mercoledì 21 dicembre 2011 17.01 A: Andrea Grassi Cc: 'Craig Ringer'; harry...@comcast.net; 'Pg Bugs'; 'Alvaro Herrera' Oggetto: Re: R: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function "Andrea Grassi" <andreagra...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
