Re: pgbench bug / limitation - Mailing list pgsql-bugs

From Tom Lane
Subject Re: pgbench bug / limitation
Date
Msg-id 1509305.1591378355@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench bug / limitation  (Andres Freund <andres@anarazel.de>)
Responses Re: pgbench bug / limitation  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
Andres Freund <andres@anarazel.de> writes:
> On June 5, 2020 9:45:47 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The idea that I vaguely had was to build our own array of socket FDs
>> (bypassing the unnecessary de-duplication logic in FD_SET) and then
>> call WaitForMultipleObjects() or similar directly.

> IIRC WaitForMultiple* only supports 64 objects or such. Which might be problematic here.

Ugh, so it does.  I'd also just noted that its timeout resolution is
only in msec, which is exactly why we want to use ppoll() not poll()
here on Unix-oid OS's.  So WaitForMultipleObjects() is out.

I still suppose that select(2) is not a native API for Windows.  Since
we know that it can be made to support more than 64 FDs, it must not
be built on top of WaitForMultipleObjects ... but then what *is* it
built on?

            regards, tom lane



pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgbench bug / limitation
Next
From: Andres Freund
Date:
Subject: Re: pgbench bug / limitation