Re: pgbench bug / limitation
От | Tom Lane |
---|---|
Тема | Re: pgbench bug / limitation |
Дата | |
Msg-id | 1507639.1591375547@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgbench bug / limitation (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: pgbench bug / limitation
Re: pgbench bug / limitation |
Список | pgsql-bugs |
David Rowley <dgrowleyml@gmail.com> writes: > On Tue, 2 Jun 2020 at 23:27, Fabien COELHO <coelho@cri.ensmp.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
В списке pgsql-bugs по дате отправления: