Skip site navigation (1) Skip section navigation (2)

Re: seg regression failures

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: (view raw or whole 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.


In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-03-23 18:46:27
Subject: Re: seg regression failures
Previous:From: Tom LaneDate: 2007-03-23 16:11:14
Subject: Re: seg regression failures

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group