Re: upcoming API changes for LLVM 12

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: upcoming API changes for LLVM 12
Date: 2020-10-16 22:28:19
Message-ID: 20201016222819.GA4565@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Oct-16, Andres Freund wrote:

> 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.

Is there a matrix of LLVM versions supported by live distros? It sounds
like pruning away 3.9 from branch master would be reasonable enough;
OTOH looking at the current LLVM support code in Postgres it doesn't
look like you would actually save all that much. Maybe the picture
changes with things you're doing now, but it's not evident from what's
in the tree now.

> 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?

It seems fair to think that new Postgres releases should be put in
production only with the newest LTS release of each OS -- no need to go
back to the second newest. But I think we should use such a criteria to
drive discussion rather than as a battle axe chopping stuff away.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-10-16 22:35:51 Stats collector's idx_blks_hit value is highly misleading in practice
Previous Message Alvaro Herrera 2020-10-16 22:13:21 Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY