On 2017-04-20 20:05:02 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-04-20 19:53:02 -0400, Tom Lane wrote: > >> So ... what would you say to replacing epoll_create() with > >> epoll_create1(EPOLL_CLOEXEC) ? Then a WaitEventSet would not > >> represent inheritable-across-exec resources on any platform, > >> making it a lot easier to deal with the EXEC_BACKEND case. > > > I'm generally quite in favor of using CLOEXEC as much as possible in our > > tree. I'm a bit concerned with epoll_create1's availability tho - the > > glibc support for it was introduced in 2.9, whereas epoll_create is in > > 2.3.2. On the other hand 2.9 was released 2008-11-13. > > Also, if it's not there we'd fall back to using plain poll(), which is > not so awful that we need to work hard to avoid it. I'd just as soon > keep the number of combinations down.
Just using fcntl(SET, CLOEXEC) wound't increase the number of combinations? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
