Re: [HACKERS] Unportable implementation of background worker start
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Unportable implementation of background worker start |
Дата | |
Msg-id | 12307.1493325329@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Unportable implementation of background worker start (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Unportable implementation of background worker start
|
Список | pgsql-hackers |
Andres Freund <andres@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" :-(. 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. It looks like it might be sufficient to do "#ifdef EPOLL_CLOEXEC" in latch.c, rather than bothering with a full-blown configure check. regards, tom lane
В списке pgsql-hackers по дате отправления: