Re: pgbench bug / limitation
От | Tom Lane |
---|---|
Тема | Re: pgbench bug / limitation |
Дата | |
Msg-id | 512846.1591057287@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgbench bug / limitation (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: pgbench bug / limitation
|
Список | pgsql-bugs |
David Rowley <dgrowleyml@gmail.com> writes: > I added the following line to the top of add_socket_to_set(): > printf("add_socket_to_set fd = %d\n", fd); > However, on Windows, I get: > add_socket_to_set fd = 392 > add_socket_to_set fd = 388 > add_socket_to_set fd = 408 > add_socket_to_set fd = 404 > add_socket_to_set fd = 412 > add_socket_to_set fd = 420 Interesting. > Shouldn't: if (fd < 0 || fd >= FD_SETSIZE) just become: if (idx > FD_SETSIZE) ? Certainly not, because it's the fd not the idx that is being added into the fd_set. I am not too sure about the underlying implementation on Windows, but on Unix-like OSes, FD_SETSIZE *is* the size of that bit array. What you suggest would allow memory stomps. Given your results, I'm guessing that we are indeed managing to increase the fd_set size to 1024, but that's not enough to allow order-of-1000 connections because there are other things competing for FD identifiers. Maybe we should just crank up the forced value of FD_SETSIZE (to, say, 8192)? regards, tom lane
В списке pgsql-bugs по дате отправления: