On 2015-01-20 11:10:53 -0500, Robert Haas wrote:
> On Tue, Jan 20, 2015 at 10:30 AM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > Tom Lane wrote:
> >> Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches.
> >> With this optimization flag enabled, recent versions of gcc can generate
> >> incorrect code that assumes variable-length arrays (such as oidvector)
> >> are actually fixed-length because they're embedded in some larger struct.
> >> The known instance of this problem was fixed in 9.2 and up by commit
> >> 8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides
> >> actually-variable-length catalog fields from the compiler altogether.
> >> And we plan to gradually convert variable-length fields to official
> >> "flexible array member" notation over time, which should prevent this type
> >> of bug from reappearing as gcc gets smarter. We're not going to try to
> >> back-port those changes into older branches, though, so apply this
> >> band-aid instead.
> >
> > Would anybody object to me pushing this commit to branches 8.2 and 8.3?
>
> Since those branches are out of support, I am not sure what the point
> is. If we want people to be able to use those branches reasonably we
> need to back-port fixes for critical security and stability issues,
> not just this one thing.
>
> But maybe I am missing something.
Supporting and being able to compile and run 'make check' (which doesn't
complete >= gcc 4.8) aren't the same thing though. And we e.g. try to
provide pg_dump and libpq support for older versions, which is hard to
ensure if you can't run them.
I personally think that being able to at least compile/make check old
versions a bit longer is a good idea.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services