Re: Remove latch.c workaround for Linux < 2.6.27

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.

In response to

Browse pgsql-hackers by date

  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