From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 01:10:33 |
Message-ID: | 20170427011033.csoil7rwkwv4ye5n@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-04-26 17:05:39 -0400, Tom Lane wrote:
> Here's an updated version of that, which makes use of our previous
> conclusion that F_SETFD/FD_CLOEXEC are available everywhere except
> Windows, and fixes some sloppy thinking about the EXEC_BACKEND case.
>
> 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.
> I propose to push this into HEAD and 9.6 too.
Cool.
Change looks good to me.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-04-27 01:12:58 | Re: Concurrent ALTER SEQUENCE RESTART Regression |
Previous Message | Peter Eisentraut | 2017-04-27 01:07:20 | Re: Concurrent ALTER SEQUENCE RESTART Regression |