On Thu, Sep 15, 2016 at 12:26:16PM -0700, Andres Freund wrote: > 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.
Advertising
Not when you take into account that it's been written over 20 years ago ;) > 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 Looks ok, but your milage may vary. I've seen strange subtle bugs using kqeue.. struct kevent { __uintptr_t ident; /* identifier for this event */ short filter; /* filter for event */ u_short flags; u_int fflags; quad_t data; void *udata; /* opaque user data identifier */ }; > > 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... In our use case it's about 30. > 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 ... ? Every read is an event, and that's what PostmasterIsAlive does. Marco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
