Hi, On 2016-09-15 15:57:55 +0200, Marco Pfatschbacher wrote: > the current implementation of PostmasterIsAlive() uses a pipe to > monitor the existence of the postmaster process. > One end of the pipe is held open in the postmaster, while the other end is > inherited to all the auxiliary and background processes when they fork. > This leads to multiple processes calling select(2), poll(2) and read(2) > on the same end of the pipe. > While this is technically perfectly ok, it has the unfortunate side > effect that it triggers an inefficient behaviour[0] in the select/poll > implementation on some operating systems[1]: > The kernel can only keep track of one pid per select address and > thus has no other choice than to wakeup(9) every process that > is waiting on select/poll.
Yikes, that's a pretty absurd implementation. Does openbsd's kqueue implementation have the same issue? There's http://archives.postgresql.org/message-id/CAEepm%3D37oF84-iXDTQ9MrGjENwVGds%2B5zTr38ca73kWR7ez_tA%40mail.gmail.com > Attached patch avoids the select contention by using a > separate pipe for each auxiliary and background process. I'm quite unenthusiastic about forcing that many additional file descriptors onto the postmaster... I'm not quite sure I understand why this an issue here - there shouldn't ever be events on this fd, so why is the kernel waking up all processes? It'd kinda makes sense it'd wake up all processes if there's one waiting, but ... ? > BUGS > [...] > "Internally to the kernel, select() and pselect() work poorly if multiple > processes wait on the same file descriptor. Given that, it is rather > surprising to see that many daemons are written that way." Gee. Maybe it's more surprising that that issue isn't being addressed? Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
