From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Sandro Santilli <strk(at)keybit(dot)net>, pgsql-bugs(at)postgresql(dot)org, peter_e(at)gmx(dot)net |
Subject: | Re: cache lookup failed from empty plpythonu function |
Date: | 2013-01-25 22:44:00 |
Message-ID: | 24397.1359153840@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-01-25 17:07:59 -0500, Tom Lane wrote:
>> Neither version of gcc I tried complained about this, and I assume yours
>> didn't either, which is a bit annoying/scary. I wonder whether the
>> "volatile" marker prevents that?
> I think the control flow is just to complex for gcc, it probably cannot
> trace anything across a setjmp() althout it theoretically should be
> possible given the failure is in the branch that is executed
> unconditionally.
> Given that the real culprit is 'found' I don't think its the volatiles.
Yeah, but if it had warned about the volatiles you'd probably not have
missed the more significant issue. I think the reason 'found' wasn't
complained of is that its address gets passed to another function ---
IME that seems to shut off any initialization warning, even if the
compiler can see that the function call might not happen. But I'd
have thought it'd warn about the volatiles. Anyway, not our problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-26 01:09:05 | Re: Re: BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262" |
Previous Message | Andres Freund | 2013-01-25 22:38:59 | Re: cache lookup failed from empty plpythonu function |