Re: pgsql: Refactor script execution state machine in pgbench.
От | Tom Lane |
---|---|
Тема | Re: pgsql: Refactor script execution state machine in pgbench. |
Дата | |
Msg-id | 23001.1474932337@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Refactor script execution state machine in pgbench. (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pgsql: Refactor script execution state machine in
pgbench.
Re: pgsql: Refactor script execution state machine in pgbench. Re: pgsql: Refactor script execution state machine in pgbench. |
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: