Thomas Munro <thomas.munro@gmail.com> writes:
> I wonder if there is a good way to make this sort of thing more
> systematic. If we could agree on a guiding principle vaguely like the
> above, then perhaps we just need a wiki page that lists relevant
> distributions, versions and EOL dates, that could be used to reduce
> the combinations of stuff we have to consider and make the pruning
> decisions into no-brainers.
FWIW, I think "compile older Postgres on newer infrastructure"
is a more common and more defensible scenario than "compile
newer Postgres on older infrastructure". We've spent a ton of
effort on the latter scenario (and I've helped lead the charge
in many cases), but I think the real-world demand for it isn't
truly that high once you get beyond a year or two back. On the
other hand, if you have an app that depends on PG 11 behavioral
details and you don't want to update it right now, you might
nonetheless need to put that server onto recent infrastructure
for practical reasons.
Thus, I think it's worthwhile to spend effort on back-patching
new-LLVM compatibility fixes into old PG branches, but I agree
that newer PG branches can drop compatibility with obsolete
LLVM versions.
LLVM is maybe not the poster child for these concerns -- for
either direction of compatibility problems, someone could build
without JIT support and not really be dead in the water.
In any case, I agree with your prior decision to not touch v11
for this. With that branch's next release being its last,
I think the odds of introducing a bug we can't fix later
outweigh any arguable portability gain.
regards, tom lane
