Re: pgsql: Track LLVM 15 changes.
От | Thomas Munro |
---|---|
Тема | Re: pgsql: Track LLVM 15 changes. |
Дата | |
Msg-id | CA+hUKGLqengPszjoQeD_7nmHsjGZS380+ymke-Fm=nNGMEQuhw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Track LLVM 15 changes. (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: pgsql: Track LLVM 15 changes.
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: