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
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 |