From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: seg regression failures |
Date: | 2007-03-23 18:22:50 |
Message-ID: | 46041AFA.9070701@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Anyway, I think you probably need to load up the old debugger and put a
>> break point in the overlap function ... surely the error can't be in
>> float4in or else we'd have seen other regression problems.
>
> One of the failing test cases is for seg_over_left, which is so trivial
> that it's pretty hard to believe even a Microsoft compiler could get it
> wrong ;-). My bet is something wrong in segparse.y or possibly
> segscan.l, leading to garbage seg values being produced. We've seen
> segparse.y trigger compiler bugs before --- look at its CVS history.
Loading up the debugger (I'm so happy not to have gdb-win32 now :-P), I
get some interesting stuff. My test case is "SELECT '1'::seg &&
'2'::seg" which should return false, but returns true.
I also tried seg_overlap('1'::seg,'2'::seg) to make the path easier, but
same problem - still returns 't' when it should return'f'.
The SEG parameters going into seg_overlap() look perfectly correct, and
seg_overlap() actually returns 0. But this is somehow later turned into
't'. Any pointers for where to look for how that happens?
For example, calling seg_same('1'::seg,'2'::seg) works fine, so it's not
something in general with bool functions, or with the input functions.
In fact, those two functions looks very very similar to me.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-23 18:46:27 | Re: seg regression failures |
Previous Message | Tom Lane | 2007-03-23 16:11:14 | Re: seg regression failures |