Re: Fix compilation failure against LLVM 11

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jesse Zhang <sbjesse(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix compilation failure against LLVM 11
Date: 2020-04-28 04:56:23
Message-ID: 20200428045623.GD279958@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 27, 2020 at 07:48:54AM -0700, Jesse Zhang wrote:
> Are you expressing a concern against "churning" this part of the code in
> reaction to upstream LLVM changes? I'd agree with you in general. But
> then the question we need to ask is "will we need to revert this 3 weeks
> from now if upstream reverts their changes?", or "we change X to Y now,
> will we need to instead change X to Z 3 weeks later?".

My concerns are a mix of all that, because we may finish by doing the
same verification work multiple times instead of fixing all existing
issues at once. A good thing is that we may be able to conclude
rather soon, it looks like LLVM releases a new major version every 3
months or so.

> In that frame of
> mind, the answer is simply "no" w.r.t this patch: it's removing an
> #include that simply has been dead: the upstream change merely exposed
> it.

The docs claim support for LLVM down to 3.9. Are versions older than
8 fine with your proposed change?

> OTOH, is your concern more around "how many more dead #include will LLVM
> 11 reveal before September?", I'm open to suggestions. I personally have
> a bias to keep things working.

This position can have advantages, though it seems to me that we
should still wait to see if there are more issues popping up.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-04-28 04:58:57 Re: [HACKERS] Restricting maximum keep segments by repslots
Previous Message Michael Paquier 2020-04-28 04:31:23 Re: pg_rewind docs correction