On 2015-01-20 11:10:53 -0500, Robert Haas wrote: > On Tue, Jan 20, 2015 at 10:30 AM, Alvaro Herrera > <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
