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  (David Rowley <dgrowleyml@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: pgbench bug / limitation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgbench bug / limitation