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: 46041AFA.9070701@hagander.net (view raw or flat)
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

In response to

Responses

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-2014 The PostgreSQL Global Development Group