Re: cache lookup failed from empty plpythonu function

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

In response to

Browse pgsql-bugs by date

  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