ticket #304 regress is failing

[robe]

My regress tickets is failing now. I though it was just the line breaks, but I fixed that and it still fails. It used to pass like yesterday or the day before as I recall.

Below is the output of the diff.

-- tickets_expected    Fri Feb 25 17:22:52 2011
+++ /tmp/pgis_reg_5508/test_57_out      Fri Mar 18 15:10:03 2011
@@ -63,8 +63,8 @@
 #277|<gml:Point><gml:coordinates>1,1e+308</gml:coordinates></gml:Point>
 #299|2
 #304
-#304.a|21
-#304.b|1
+#304.a|0
+#304.b|0
 #408|IllegalArgumentException: point array must contain 0 or >1 elements
 NOTICE:  IllegalArgumentException: point array must contain 0 or >1 elements
 #408.1|f
~          

[robe]

strk's note from #869 My regress tickets is failing now. I though it was just the line breaks, but I fixed that and it still fails. It used to pass like yesterday or the day before as I recall.

Below is the output of the diff.

-- tickets_expected    Fri Feb 25 17:22:52 2011
+++ /tmp/pgis_reg_5508/test_57_out      Fri Mar 18 15:10:03 2011
@@ -63,8 +63,8 @@
 #277|<gml:Point><gml:coordinates>1,1e+308</gml:coordinates></gml:Point>
 #299|2
 #304
-#304.a|21
-#304.b|1
+#304.a|0
+#304.b|0
 #408|IllegalArgumentException: point array must contain 0 or >1 elements
 NOTICE:  IllegalArgumentException: point array must contain 0 or >1 elements
 #408.1|f

~

[strk]

a bisect points finger at r6924, by pramsey.

[robe]

Oops sorry strk — my cut and paste skills are evidentally not sharp this early in the morning strks' note from #890: This happens with trunk. Possible the cause for Hudson to complain, but didn't check…

--- tickets_expected    2011-02-24 15:31:32.000000000 +0100
+++ /tmp/pgis_reg_24687/test_59_out     2011-03-28 09:55:02.000000000 +0200
@@ -63,8 +63,8 @@
 #277|<gml:Point><gml:coordinates>1,1e+308</gml:coordinates></gml:Point>
 #299|2
 #304
-#304.a|21
-#304.b|1
+#304.a|0
+#304.b|0
 #408|IllegalArgumentException: point array must contain 0 or >1 elements
 NOTICE:  IllegalArgumentException: point array must contain 0 or >1 elements
 #408.1|f

[strk]

A note: the same #304 test fails on 32bit linux too (in addition to 64bit linux). With same results: counts 0 items from both these queries:

SELECT '#304.a', Count(*) FROM utm_dots WHERE ST_DWithin(the_geog, 'POINT(0 0)'::geography, 3000000);

CREATE INDEX utm_dots_gix ON utm_dots USING GIST (the_geog);
SELECT '#304.b', Count(*) FROM utm_dots WHERE ST_DWithin(the_geog, 'POINT(0 0)'::geography, 300000);

Whereas 21 and 1 are expected, respectively.

[strk]

Looking at the culprit changeset (r6924) this was suspicious:

- if ( gserialized_datum_overlaps(PG_GETARG_DATUM(0),PG_GETARG_DATUM(1)) == LW_TRUE ) 
+ if ( gserialized_datum_predicate(PG_GETARG_DATUM(0),PG_GETARG_DATUM(1), gidx_contains) == LW_TRUE ) 

The attached patch uses 'gidx_overlaps' instead of 'gidx_contains'. Fixes regress/ make check for me.

[strk]

I've committed the patch as of r7007