On 2017-04-27 16:35:29 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-04-26 17:05:39 -0400, Tom Lane wrote: > >> I went ahead and changed the call to epoll_create into epoll_create1. > >> I'm not too concerned about loss of portability there --- it seems > >> unlikely that many people are still using ten-year-old glibc, and > >> even less likely that any of them would be interested in running > >> current Postgres on their stable-unto-death platform. We could add > >> a configure test for epoll_create1 if you feel one's needed, but > >> I think it'd just be a waste of cycles. > > > Yea, I think we can live with that. If we find it's a problem, we can > > add a configure test later. > > Well, according to the buildfarm, "later" is "now" :-(.
Too bad. > If RHEL5 is too old to have epoll_create1, I think your dates for it > might be a bit off. Anyway, I'll go do something about that in a > little bit. 2008-11-13 is when glibc 2.9 was released. Appears that RHEL5 still ships with glibc 2.5, released 2006-09-29. Given that RHEL 5 originally was released 2007-03-05, that's not too surprising? > It looks like it might be sufficient to do "#ifdef EPOLL_CLOEXEC" > in latch.c, rather than bothering with a full-blown configure check. Yea, that sounds worth trying. Wonder if we need to care about kernels not supporting it, but glibc having support? I'd be ok skimping on that for now. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
