Fabien COELHO <coelho@cri.ensmp.fr> writes:
> Could you catch the process to identify the infinite loop?
I think the problem is here (pgbench.c lines 4550ff):
bool ready;
...
ready = FD_ISSET(sock, &input_mask);
The result of FD_ISSET isn't a bool, it's an int. I can see in the
looping process that the backend connection has socket FD 8, and
I think what is happening is that FD_ISSET is returning 1<<8 and
that's getting truncated to zero to fit in a bool (char), so that
the code just below doesn't call doCustom and we never consume the
waiting result.
I couldn't reproduce this in a manual build, but perhaps the socket
number assignments are a bit different in the buildfarm environment.
Rather than s/bool/int/, I'm inclined to remove the "ready" variable
altogether. We have exactly zero other places that make any assumptions
about the width of FD_ISSET results, and I don't see a good reason
why this needs to be the first one.
I see a number of other things that look pretty infelicitous in this
code --- for example, why is the loop at lines 4440ff break'ing after
it comes across the first socket to wait for? That sure looks like it
will fail to deal with more than one wait-able socket, rather destroying
the point of having multiple threads.
Will fix.
regards, tom lane
