On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> >> If we turn off the optimization, that will fix any other cases as well,
> >> no? So why would we risk breaking third-party code by back-porting the
> >> struct declaration changes?
>
> > The -fno-agressive-loop thingie afaics only controls the optimization
> > with regard to loopey constructs, not in general. I *think* there are
> > independent hazards with general unreachability detection. Not sure
> > whether they trigger at -O2 or only at -O3 though.
>
> I'm not excited about breaking code in order to fix optimization bugs
> that are purely hypothetical (and for which there's no particular reason
> to believe that the proposed change would fix them anyway). If we were
> seeing such things in the field it would be a different story.
Well, given the problems we're discussing here, it's not all that
hypothetical. Obviously the compiler *does* have information it believes
to proof some code to be unreachable. And we know that information comes
from the way the catalog structs are declared.
I don't really fancy finding more and more optimizations we didn't think
about and disabling them one by one after annoying debugging sessions.
Also, just about all code that would get broken by that change would be
code that's already pretty much broken.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services