Re: Remove latch.c workaround for Linux < 2.6.27

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-02-28T22:30:24Z
Lists: pgsql-hackers
On Sat, Feb 27, 2021 at 9:30 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Sat, Feb 27, 2021 at 9:01 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > What happens if you try to try to compile or run on such an ancient kernel? Does it fall back to something else? Can you still make it work with different configure options?
> >
> > I'm just curious, not objecting.
>
> With this patch, I guess you'd have to define WAIT_USE_POLL.  I
> suppose we could fall back to that automatically if EPOLL_CLOEXEC
> isn't defined, if anyone thinks that's worth bothering with.

I thought about doing:

 /* don't overwrite manual choice */
-#elif defined(HAVE_SYS_EPOLL_H)
+#elif defined(HAVE_SYS_EPOLL_H) && defined(EPOLL_CLOEXEC)
 #define WAIT_USE_EPOLL

... but on reflection, I don't think we should expend energy on a
desupported OS vintage that isn't present in our build farm, at least
not without a reasonable field complaint; I wouldn't even know if it
worked.

So, pushed without that.



Commits

  1. Remove latch.c workaround for Linux < 2.6.27.

  2. Cope with glibc too old to have epoll_create1().