| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Unportable implementation of background worker start |
| Date: | 2017-04-27 21:06:24 |
| Message-ID: | 14570.1493327184@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-04-27 16:35:29 -0400, Tom Lane wrote:
>> 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.
On my RHEL6 box, <sys/epoll.h> is provided by glibc not the kernel:
$ rpm -qf /usr/include/sys/epoll.h
glibc-headers-2.12-1.209.el6_9.1.x86_64
So I think it's probably safe to assume that the header is in sync
with what glibc can do.
As for kernel (much) older than glibc, I'd rather expect glibc to paper
over that, though I've not looked at the source code to be sure.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-04-27 21:22:25 | Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range |
| Previous Message | Andres Freund | 2017-04-27 20:45:05 | Re: Unportable implementation of background worker start |