public inbox for [email protected]  

help / color / mirror / Atom feed

From: Thomas Munro <[email protected]>
To: Fabien COELHO <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: pgsql-committers <[email protected]>
Subject: Re: pgsql: Track LLVM 15 changes.
Date: Tue, 15 Feb 2022 09:59:32 +1300
Message-ID: <CA+hUKGLqengPszjoQeD_7nmHsjGZS380+ymke-Fm=nNGMEQuhw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2202141604550.3363256@pseudo>
References: <[email protected]>
	<alpine.DEB.2.22.394.2202141604550.3363256@pseudo>

On Tue, Feb 15, 2022 at 4:06 AM Fabien COELHO <[email protected]> wrote:
> > This isn't an API change, it's just a missing #include that we got away
> > with before.  Per buildfarm animal seawasp.
>
> If it is a somehow *missing* include, should it be back-patched? Not sure,
> just asking.

Arguably (I think it'd work fine on ancient LLVM as far back as we
currently support, based on the age of that header[1]), but since
there's no actual problem with older LLVM releases, I figured we
should let sleeping dogs lie.

My general plan for this stuff is to try to do just one back-patch for
each LLVM release, with all the changes in it, to reduce commit churn.
Hence commit messages that say "Track LLVM X ..." so that it's easy to
find all the changes for X around the time of X's release.  In other
words I'll probably do the 14 back-patch next month, so our May
releases will compile and work against LLVM 14, due out in March.
Then I'll scoop up the accumulated 15 stuff around October or whatever
it turns out to be.  (With 13 I "pre-empted" their release with commit
9b4e4cfe, because we could still compile OK against 13 but we would
crash on some queries, so it seemed worth the extra effort to avoid
having that situation in the field, but I'm not sure if releasing
"before" them is really sustainable; I'd have had to get the 14
changes into our recent release, before their RC1.)  Open to better
ideas about how we should manage this stuff.

[1] https://github.com/llvm/llvm-project/blob/llvmorg-3.9.0/llvm/include/llvm/Support/MemoryBuffer.h

view thread (15+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pgsql: Track LLVM 15 changes.
  In-Reply-To: <CA+hUKGLqengPszjoQeD_7nmHsjGZS380+ymke-Fm=nNGMEQuhw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox