MIME-Version: 1.0
References: <E1nJRXj-000224-Kt@gemulon.postgresql.org>
 <alpine.DEB.2.22.394.2202141604550.3363256@pseudo>
In-Reply-To: <alpine.DEB.2.22.394.2202141604550.3363256@pseudo>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Tue, 15 Feb 2022 09:59:32 +1300
Message-ID: 
 <CA+hUKGLqengPszjoQeD_7nmHsjGZS380+ymke-Fm=nNGMEQuhw@mail.gmail.com>
Subject: Re: pgsql: Track LLVM 15 changes.
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Thomas Munro <tmunro@postgresql.org>,
	pgsql-committers <pgsql-committers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BhUKGLqengPszjoQeD_7nmHsjGZS380%2Bymke-Fm%3DnNGMEQuhw%40mail.gmail.com>
Precedence: bulk

On Tue, Feb 15, 2022 at 4:06 AM Fabien COELHO <coelho@cri.ensmp.fr> 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