#4210 closed defect (fixed)
PostGIS 3.0 is completely broken
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 3.0.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
I see none of the bots are happy with the latest change.
Split core and sfcgal tests allowing to run one w/out the other Closes #4200 (detail) by Sandro Santilli
Change History (11)
comment:1 by , 6 years ago
Owner: | changed from | to
---|
comment:2 by , 6 years ago
comment:3 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Sorry, should be fixed with r16930 (I inadvertently left the default make target under regress/ to be "check" instead of a do-nothing rule)
comment:4 by , 6 years ago
r16936 hopefully makes _all_ bots happy (after a few more commits making happy some of them)
comment:5 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
They are still all broken
Now with this error:
geography .. failed (diff expected obtained: /projects/postgis/tmp/3.0.0dev_pg10_geos3.7.0_gdal2.2.4w64/test_3_diff) ----------------------------------------------------------------------------- --- geography_expected 2018-09-11 02:20:56.083471300 -0400 +++ /projects/postgis/tmp/3.0.0dev_pg10_geos3.7.0_gdal2.2.4w64/test_3_out 2018-10-29 11:03:40.592624400 -0400 @@ -1,3 +1,4 @@ +ERROR: duplicate key value violates unique constraint "spatial_ref_sys_pkey" geog_distance_cached_1a|t geog_distance_cached_1b|t geog_distance_cached_1c|t -----------------------------------------------------------------------------
comment:6 by , 6 years ago
Slight correction that's what I see on debbie and winnie. Travis seems to be okay so maybe it's happening on one of the tests that only winnie and debbie do.
Bessies are having an issue too but I think theres may be different one.
Investigating.
comment:8 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:9 by , 6 years ago
Thanks for fixing this Regina ! Just a comment: a left-over entry in spatial-ref-sys sounds like a bug in a previously run test. I think it would make more sense to fix the previous test to cleanup after itself rather than (or in addition to) making tests tolerate a possibly dirty starting point.
Beside, we might want to _avoid_ using system SRIDs for tests (what if you run run_test.pl --nocreate and set PGIS_REG to an existing database?)
comment:10 by , 6 years ago
Can we randomize test order so that we may catch these?
There is some test (I think regress/tickets?) that does 'delete from spatial_ref_sys;'. I once did that on my laptop's db without run_test and now I'm without my spatial_ref_sys entries.
comment:11 by , 6 years ago
Why not begin a transaction at the start of each test and roll back at the end? Adding randomness seems like a recipe for more confusion.
For reference this is what debbie is showing:
Dronie:
Travis: