| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: upcoming API changes for LLVM 12 |
| Date: | 2020-10-16 20:53:48 |
| Message-ID: | 20201016205348.yyremsicin5hdpph@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2020-10-16 10:22:57 -0400, Tom Lane wrote:
> Yeah. As long as we're not breaking the ability to build against older
> LLVM, I can't see a reason not to apply and back-patch these changes.
> We usually want all supported PG versions to build against newer tool
> chains, and this seems to fall into that category.
Cool! I just ran that branch against 3.9 (the currently oldest supported
version), and that still works.
A related question is whether it'd be time to prune the oldest supported
LLVM version. 3.9.0 was released 2016-08-31 (and 3.9.1, the only point
release, was 2016-12-13). There's currently no *pressing* reason to
reduce it, but it is the cause of few #ifdefs - but more importantly it
increases the test matrix.
I'm inclined to just have a deterministic policy that we apply around
release time going forward. E.g. don't support versions that are newer
than the newest available LLVM version in the second newest
long-term-supported distribution release of RHEL, Ubuntu, Debian?
Regards,
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-10-16 20:56:47 | Re: Internal key management system |
| Previous Message | Bruce Momjian | 2020-10-16 20:24:37 | Re: Internal key management system |