| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, David Rowley <dgrowleyml(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "Jawarilal, Manish" <Manish(dot)Jawarilal(at)dell(dot)com> |
| Subject: | Re: pgbench bug / limitation |
| Date: | 2020-06-05 17:32:35 |
| Message-ID: | 1509305.1591378355@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On June 5, 2020 9:45:47 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-06-05 17:44:18 | Re: pgbench bug / limitation |
| Previous Message | Andres Freund | 2020-06-05 17:18:40 | Re: pgbench bug / limitation |