Re: pgbench bug / limitation

On Sat, 6 Jun 2020 at 06:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I'm fairly sure one can easily scale to large numbers of sockets on
> > windows by using completion based APIs, but that doesn't seem like a
> > realistic thing to use for pgbench anytime soon.
>
> Agreed. Seems like the best answer is to get in bed with the Windows
> representation of fd_set, since we cannot avoid knowing that it is
> different from other platforms' versions. I suggest that we might as
> well get all the way in and dodge the FD_SETSIZE limitation altogether,
> as per the attached utterly-untested draft patch.

I compiled this on Visual Studio 2017 and tested it. I didn't
encounter any problems.

The only thing I see in Winsock2.h that relies on FD_SETSIZE being the
same size as the fd_set array is the FD_SET macro. So, I think it
should be safe if these differ, like they will with your patch. We'll
just need to make sure we don't use FD_SET in the future.

> A remaining problem with this is that in theory, repeatedly applying
> socket_has_input() after the wait could also be O(N^2) (unless FD_ISSET
> is way smarter than I suspect it is).

The FD_ISSET() just calls a function, so I don't know what's going on
under the hood.

#define FD_ISSET(fd, set) __WSAFDIsSet((SOCKET)(fd), (fd_set FAR *)(set))

However, I don't see what else it could do other than loop over the
array until it finds a match.

David