From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove latch.c workaround for Linux < 2.6.27 |
Date: | 2021-02-28 22:30:24 |
Message-ID: | CA+hUKGL7kSrA37ArbxaQUofUDwTQfsE7904OmxKcuePdnfD6LQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Feb 27, 2021 at 9:30 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Sat, Feb 27, 2021 at 9:01 PM Heikki Linnakangas <hlinnaka(at)iki(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-02-28 23:08:17 | Re: Different compression methods for FPI |
Previous Message | Zhihong Yu | 2021-02-28 22:27:44 | Re: [PATCH] refactor ATExec{En,Dis}ableRowSecurity |