Re: pgbench bug / limitation

On Tue, 2 Jun 2020 at 03:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hmph. Seems like that FD_SETSIZE manipulation isn't doing what we expect
> it to, then. But Windows isn't my thing, so somebody else will have to
> investigate that.

I had a look at this and it appears like we might be making some
assumptions about what socket() returns that perhaps we shouldn't be.

I added the following line to the top of add_socket_to_set():

printf("add_socket_to_set fd = %d\n", fd);

On Linux, using CFLAGS="-D PGBENCH_USE_SELECT", I see:

$ pgbench -c 122 -r -t 1 postgres
starting vacuum...end.
add_socket_to_set fd = 3
add_socket_to_set fd = 4
add_socket_to_set fd = 5
add_socket_to_set fd = 6
add_socket_to_set fd = 7
add_socket_to_set fd = 8
<trim>

However, on Windows, I get:
>pgbench -c 122 -r -T 3600 postgres
starting vacuum...end.
add_socket_to_set fd = 392
add_socket_to_set fd = 388
add_socket_to_set fd = 408
add_socket_to_set fd = 404
add_socket_to_set fd = 412
add_socket_to_set fd = 420
<trim>

So it seems to me that the range test in add_socket_to_set() is
incorrectly using the socket descriptor to determine if we've added
too many descriptors to the set. I can't glean too much from the
socket() documentation for either OS about what the return value is.
I didn't see anything which indicated anything about how the return
value is determined. My guess is that on windows it's shared over all
programs and it's not on Linux.

Shouldn't: if (fd < 0 || fd >= FD_SETSIZE) just become: if (idx > FD_SETSIZE) ?

David