Berrie64 pg13 branch - weird regress failure on tickets

[robe]

I'm going to retest this to make sure it's not a fluke. Odd that it's happening only on berrie64 which rarely has problems.

17:34:03 Checking for shp2pgsql ... found
17:34:03 Checking for pgsql2shp ... found
17:34:03 TMPDIR is /tmp/pgis_reg
17:34:03 Creating database 'postgis_reg' 
17:34:06 Preparing db 'postgis_reg' using: CREATE EXTENSION postgis SCHEMA public
17:34:11 PostgreSQL 13beta2 on aarch64-unknown-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
17:34:11   Postgis 3.1.0dev - (e6c9403) - 2020-08-13 21:20:36
17:34:11   scripts 3.1.0dev e6c9403
17:34:11   GEOS: 3.7.1-CAPI-1.11.1 27a5e771
17:34:11   PROJ: Rel. 5.2.0, September 15th, 2018

17:35:44 -----------------------------------------------------------------------------
17:35:44 --- tickets_expected	2020-08-13 14:19:28.517337391 -0700
17:35:44 +++ /tmp/pgis_reg/test_103_out	2020-08-13 14:35:44.156985845 -0700
17:35:44 @@ -433,4 +433,4 @@
17:35:44  #4670-3|LINESTRING(0 0,1 1,3 3,2 2,4 4)
17:35:44  #4670-4|LINESTRING(0 0,1 1,3 3,4 4,2 2)
17:35:44  ERROR:  LWGEOM_addpoint: Invalid offset
17:35:44 -#4689|0
17:35:44 +#4689|5.92515031139973e-11
17:35:44 -----------------------------------------------------------------------------

[robe]

oh wait it's been failing for more than this run so not a fluke

[robe]

the test that is failing is this which is to test #4689

SELECT '#4689', _ST_DistanceTree('POLYGON ((30 10, 40 40, 20 40, 30 10))'::geography, 'POLYGON((81 6,140 35,-70 18,-51 0,-60 -46,106 -6,81 6))

[robe]

Maybe this was left over from something -- the 3.0 that I triggered seemed to have passed. I'll trigger 2.5 run and see if it still shows error.

[robe]

okay guess this was a fluke maybe it had something to do with a loose liblwgeom somewhere that got cleared. 2.5 seems to have passed the hump already.

[robe]

okay it happened againbut in 3.1.0 run. Seems random.

Okay

03:37:19 PostgreSQL 13beta2 on aarch64-unknown-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
03:37:19   Postgis 3.1.0dev - (866293b) - 2020-08-15 07:25:55
03:37:19   scripts 3.1.0dev 866293b
03:37:19   GEOS: 3.7.1-CAPI-1.11.1 27a5e771
03:37:19   PROJ: Rel. 5.2.0, September 15th, 2018
03:37:19 

03:38:25 --- tickets_expected	2020-08-15 00:24:42.348748491 -0700
03:38:25 +++ /tmp/pgis_reg/test_103_out	2020-08-15 00:38:25.380045943 -0700
03:38:25 @@ -433,4 +433,4 @@
03:38:25  #4670-3|LINESTRING(0 0,1 1,3 3,2 2,4 4)
03:38:25  #4670-4|LINESTRING(0 0,1 1,3 3,4 4,2 2)
03:38:25  ERROR:  LWGEOM_addpoint: Invalid offset
03:38:25 -#4689|0
03:38:25 +#4689|5.92515031139973e-11

[Algunenano]

I'm also seeing this in my local dev machine after updating to HEAD:

--- tickets_expected    2020-08-17 16:08:40.810017012 +0200
+++ /tmp/pgis_reg/test_103_out  2020-08-17 16:29:56.118769957 +0200
@@ -433,4 +433,4 @@
 #4670-3|LINESTRING(0 0,1 1,3 3,2 2,4 4)
 #4670-4|LINESTRING(0 0,1 1,3 3,4 4,2 2)
 ERROR:  LWGEOM_addpoint: Invalid offset
-#4689|0
+#4689|5.9583730430112e-11

[robe]

@Algunenano does it happen on your machine consistently? I've only seen it on the Rasberry Pi 64 and I think it doesn't always happen.

I thought originally it was pramsey's change in #4689 but I'm guessing it might not be the code change and it's just the addition of the test he aded that is exposing an issue that has always been there.

[Algunenano]

@Algunenano does it happen on your machine consistently? I've only seen it on the Rasberry Pi 64 and I think it doesn't always happen.

Yes, it happens everytime I run the regress tests. I'm building with clang, both with -O2 and with -march=native -mtune=native -O3. Using GEOS HEAD.

[Algunenano]

It seems this looks similar to #2168.

In geography_distance there is a round to nanometers to avoid this:

	/* Knock off any funny business at the nanometer level, ticket #2168 */
	distance = round(distance * INVMINDIST) / INVMINDIST;

Which is not present in geography_distance_tree. @pramsey do you think it's the same issue and should be solved in the same way or it should be investigated further?

[Algunenano]

This is still broken (so it's a pita any time I try to do anything in Postgis, which hasn't been much recently). @pramsey any thoughts?

[pramsey]

Replying to Algunenano:

@pramsey do you think it's the same issue and should be solved in the same way or it should be investigated further?

Round it off.

[Regina Obe <lr@…>]

In 3bcbbee/git:

References #4740 Round off geography_distance_tree

[robe]

closing this out since berrie64 seems to have passed this hump.

[Algunenano]

Thanks @robe, it also fixed it for me.

[robe]

Berrie64 is having the same failure on 3.0.4dev, so reopening until we backport it to 3.0 branch.

[Paul Ramsey <pramsey@…>]

In c07bff3/git:

Match tree to brute force return in geography distance, closes #4740