Re: Remove latch.c workaround for Linux < 2.6.27

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove latch.c workaround for Linux < 2.6.27
Date: 2021-02-27 08:01:27
Message-ID: A4EC60C5-9947-4FD9-8E22-5F670B45B344@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 February 2021 01:10:23 EET, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>Hello,
>
>Commit 82ebbeb0 added a workaround for (already in 2017) ancient Linux
>kernels with no EPOLL_CLOEXEC. I don't see any such systems in the
>build farm today (and if there is one hiding in there somewhere, it's
>well past time to upgrade). I'd like to rip that code out, because
>I'm about to commit some new code that uses another 2.6.17+
>XXX_CLOEXEC flag, and it'd be silly to have to write new workaround
>code for that too, and a contradiction to have fallback code in one
>place but not another. Any objections?

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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-02-27 08:08:15 Shared memory size computation oversight?
Previous Message Andrey Borodin 2021-02-27 07:43:52 Different compression methods for FPI