[postgis-tickets] [PostGIS] #3238: SFCGAL tests failing

[PostGIS]

#3238: SFCGAL tests failing
----------------------+---------------------------
  Reporter:  strk     |      Owner:  colivier
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Milestone:  PostGIS 2.2.0
 Component:  sfcgal   |    Version:  trunk
Resolution:           |   Keywords:  testsing
----------------------+---------------------------

Comment (by pramsey):

 OK, so it's really very complex, but I've read through the backend code a
 lot now and understand it. It's really odd.

 If you connect to a database that has postgis "installed", as we know, it
 won't load the library right away, it waits until the first function call.
 And the way the GUCs respond is a little odd:
 {{{
 postgis_reg=# show postgis.backend;
 ERROR:  unrecognized configuration parameter "postgis.backend"
 postgis_reg=# show foo;
 ERROR:  unrecognized configuration parameter "foo"
 postgis_reg=# set postgis.backend = 'sfcgal';
 SET
 postgis_reg=# set foo = 'bar';
 ERROR:  unrecognized configuration parameter "foo"
 postgis_reg=# show foo;
 ERROR:  unrecognized configuration parameter "foo"
 postgis_reg=# show postgis.backend;
  postgis.backend
 -----------------
  sfcgal
 (1 row)
 }}}
 Nice, right? So on the one hand, neither postgis.backend nor foo are set,
 *but* it is legal to set postgis.backend and not foo. At this point, even
 after setting postgis.backend, the library is still not loaded, and
 _PG_init() has not yet been called. This is where the regression error is
 coming from, even though during regression we only load one library at a
 time. Now load the library, and we get the error.
 {{{
 postgis_reg=# set postgis.backend = 'sfcgal';
 SET
 postgis_reg=# select postgis_version();
 WARNING:  'postgis.backend' is currently set to 'sfcgal' and cannot be
 changed until you reconnect
             postgis_version
 ---------------------------------------
  2.2 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
 (1 row)
 }}}
 Errors just like in regression. Because our test for "can I install the
 GUC" is "is there a GUC value set", "GetConfigOption()", and yes, there's
 a value set. Also, since we fail to install the GUC formally, with
 "DefineCustomStringVariable()", we don't get the lwgeom_backend_switch()
 callback in place, so the backend never actually changes from the default
 "geos" backend, so functional regression tests also fail further down the
 line.

 How to fix this? Not sure... we want to prevent double-install of the GUC,
 which can happen during upgrade when both the old and new libraries are
 co-existing. And we want to allow DefineCustomStringVariable() to be
 called even when there's a dummy value living in the postgis.backend GUC.
 Probably we need a better way to catch the double-library case.

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3238#comment:11>
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.