Re: pgbench bug / limitation
| От | Fabien COELHO |
|---|---|
| Тема | Re: pgbench bug / limitation |
| Дата | |
| Msg-id | alpine.DEB.2.22.394.2006050637420.213031@pseudo обсуждение исходный текст |
| Ответ на | Re: pgbench bug / limitation (David Rowley <dgrowleyml@gmail.com>) |
| Список | pgsql-bugs |
Hello David, > 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. Yep. I cannot seen how to do it without some assumption about the underlying implementation. I agree that it breaks the very principle of the interface, which is to hide fdset implementation details. > I tested the patch on a Windows machine Thanks. > and it seems to work. Good. > I'm not much a fan of the naming of the new macro though. Wouldn't it > be better to reverse the logic and call it IS_VALID_FD? I hesitated. Here it is with a inversion/renaming, and a check that fd is positive on windows. I renamed to "FD_IS_VALID" which seems to read better. -- Fabien.
Вложения
В списке pgsql-bugs по дате отправления: