[postgis-tickets] [PostGIS] #3220: Mingw failure on cluster test

[PostGIS]

#3220: Mingw failure on cluster test
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Milestone:  PostGIS 2.2.0
 Component:  postgis  |    Version:  trunk
Resolution:           |   Keywords:
----------------------+---------------------------

Comment (by robe):

 Nope that one returns the same answer for me on my mingw64 that is failing
 this test:


 {{{
 test_address=# select version() || ' ' || postgis_full_version();
 NOTICE:  Function postgis_topology_scripts_installed() not found. Is
 topology support enabled and topology.sql installed?
 ?column?
 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
  PostgreSQL 9.4.4 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-win32
 -seh-rev1, Built by MinGW-W64 project) 4.8.3, 64-bit POSTGIS="2.2.0dev
 r13905" GEOS="3.5.0dev
 (1 row)


 test_address=#
 test_address=# select st_distance(
 test_address(#   'GEOMETRYCOLLECTION(LINESTRING(0 0,1 1),LINESTRING(5 5,4
 4),LINESTRING(0 0,-1 -1),POLYGON((0 0,4 0,4 4,0 4,0 0)))',
 test_address(#   'GEOMETRYCOLLECTION(LINESTRING(6 6,7 7))'
 test_address(# );
    st_distance
 -----------------
  1.4142135623731
 (1 row)

 }}}

 BTW I still get this annoying topology script not installed notice every
 once in a while.  I think that happens if I had postgis_topology installed
 and then later uninstall it.  I'll ticket that one separately if I can
 replicate.


 Reran the tests and still fails on cluster:


 {{{
 Loading PostGIS into 'postgis_reg'
 PostgreSQL 9.4.4 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-win32
 -seh-rev1, Built by MinGW-W64 project) 4.8.3, 64-bit
   Postgis 2.2.0dev - r13906 - 2015-08-15 06:08:55
   scripts 2.2.0dev r13906
   GEOS: 3.5.0dev-CAPI-1.9.0 r4072
   PROJ: Rel. 4.9.1, 04 March 2015

 }}}


 Checked still screwed:

 {{{
 SELECT 't3', ST_AsText(unnest(ST_ClusterWithin(geom, 1.39 ORDER BY id)))
 FROM cluster_inputs;


 test_address=# SELECT 't3', ST_AsText(unnest(ST_ClusterWithin(geom, 1.39
 ORDER BY id))) FROM cluster_inputs;
  ?column? |
 st_astext
 ----------+--------------------------------------------------------------------------------------------------------------------------------------
  t3       | GEOMETRYCOLLECTION(LINESTRING(0 0,1 1),LINESTRING(5 5,4
 4),LINESTRING(0 0,-1 -1),LINESTRING(6 6,7 7),POLYGON((0 0,4 0,4 4,0 4,0
 0)))
  t3       | GEOMETRYCOLLECTION(POLYGON EMPTY)
 (2 rows)

 }}}

 If I'm the only one experiencing this issue, and it's not a symptom of a
 larger issue, I'll okay with closing this as won't fix.  This behavior
 only exhibits when I am testing my 64-bit mingw binaries against my 64-bit
 mingw compiled PostgreSQL.  It doesn't happen if I use the binaries in a
 VC++ compiled EDB PostgreSQL, which is my production use and what I
 target.

 prasmey maybe I can see what it's doing if I inject so debug clauses.
 Where is the best place to put that?

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3220#comment:7>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.