Re: Crash in gist insertion on pathological box data - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Crash in gist insertion on pathological box data
Date
Msg-id 873acq27k1.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Crash in gist insertion on pathological box data  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Crash in gist insertion on pathological box data  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Teodor Sigaev <teodor@sigaev.ru> writes:>> Look at the patch, it fixes the problem by comparing for equality>> by
FPeq()macros which is used everywhere in geometry calculation.
 
Tom> Ick.  FPeq() is a crock; I'd like to see us get rid of it, notTom> spread it even further.  And what confidence do
youhave thatTom> this change eliminates all forms of the problem, anyway?
 

Here is a test case that crashes even with the patch:

create table floats3(x float8, y float8);
-- same badfloats.txt data as before
\copy floats3 from 'badfloats.txt'
update floats3 set x = x * pow(2::float8,33), y = y * pow(2::float8,33);
create table boxes1 (b box);
create index boxes1_idx on boxes1 using gist (b);
insert into boxes1 select box(point(x,x),point(y,y)) as b from floats3;
[crash]

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: [GENERAL] string_to_array with empty input
Next
From: Bruce Momjian
Date:
Subject: Re: Any reason not to return row_count in cursor of plpgsql?