Hi hackers, I've been wrestling with this one for a while and gone down a couple blind alleys, so time to ask the experts.
PostGIS has a couple things different from the extensions that live in contrib, - it has some GUCs - it has a versioned loadable library (postgis-2.1.so, postgis-2.2.so, etc) We've found that, when we run the following SQL, CREATE EXTENSION postgis VERSION '2.1.9'; ALTER EXTENSION postgis UPDATE TO '2.2.0'; The update fails, because of a collision in the GUC. When the extension is CREATEd, postgis-2.1.so is loaded, _PG_init() is called, and that in turn calls DefineCustomStringVariable() to create our GUC. When the ALTER is called, the first time a C function definition is called, the new library, postgis-2.2.so is loaded, the _PG_init() of *that* library is called, and DefineCustomStringVariable() is called, but this time it runs into the GUC definition from the first library load, and the EXTENSION update process stops as an ERROR is thrown. My initial attempt at avoiding this problem involved looking at GetConfigOption() before running DefineCustomStringVariable() to see if the GUC was already defined. This did not work, as it's possible to define a GUC before loading the library. So an otherwise innocent sequence of commands like: SET my_guc = 'foo'; -- no library loaded yet SELECT my_library_function(); -- causes library load and _PG_init() to fire Would now fail, as it hit my test for a pre-existing GUC. Unfortunately, the GUC we are using is not one where we simply read a value now and a again. It switches the backend geometry library that various functions use, so performance is a big deal: instead of reading the GUC value, the code expects that GUC changes will flip a global variable, using the GUC "assign" callback. So I need a way to either (a) notice when I already have a (old) copy of the library loaded and avoid trying to setup the GUC in that case or (b) set-up the GUC in a somewhat less brittle way than DefineCustomStringVariable() allows, something that can overwrite things instead of just erroring out. The ugly code in question is here https://github.com/postgis/postgis/blob/svn-trunk/postgis/lwgeom_backend_api.c#L105 Discussion is here https://trac.osgeo.org/postgis/ticket/2382 Thanks, P -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
