From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "Jawarilal, Manish" <Manish(dot)Jawarilal(at)dell(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgbench bug / limitation |
Date: | 2020-06-05 16:45:47 |
Message-ID: | 1507639.1591375547@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 2 Jun 2020 at 23:27, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>> Attached is a blind attempt at working around the issue based on what you
>> show below, that I cannot test.
> I suppose we might be able to do something like that. It does expose
> us to the implementation of Microsoft's fd_set struct, but surely the
> shape of that must be pretty much fixed since if it were to be changed
> then software that's already compiled would break.
More to the point, this does nothing to get around the O(N^2) cost of
adding N FDs to the fd_set with Microsoft's implementation; so I do not
think it's really going to fix the problem for people who want to use
lots of connections on Windows.
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. This would of course
be quite Windows-specific, which'd be annoying, but it seems like
getting out of using select() on Windows wouldn't be a bad thing.
Trying to make the same code work with two basically different models
of what a fd_set is seems like a recipe for pain. This would also get
us out from under the hack of redefining FD_SETSIZE.
Alternatively, if we're going to get in bed with the internals of
Windows' fd_set implementation anyway, we could implement our own
version of FD_SET that doesn't do the de-duplication.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kyle Kingsbury | 2020-06-05 17:00:18 | Re: Potential G2-item cycles under serializable isolation |
Previous Message | Kyle Kingsbury | 2020-06-05 13:02:58 | Re: Potential G2-item cycles under serializable isolation |