<div dir="ltr">Yes, certainly seems like interim measure #1 is to carefully document what a pg_upgrade upgrade looks like and it's one of<div><br></div><div>- install newest postgis in your old postgresql, ALTER EXTENSION to upgrade to that</div><div>- install new postgresql version and newest postgis in that, do the pg_upgrade</div><div>- you're done</div><div><br></div><div>or</div><div><br></div><div><div>- install new postgresql version and your current version of postgis in that, do the pg_upgrade</div><div>- install newest postgis, ALTER EXTENSION to upgrade to that, you're done</div><div><div>- you're done</div></div></div><div><br></div><div>It's not many steps, frankly. The "only" reason this is hard for casual users is because we almost always lack the "old postgis, new postgresql" or "old postgresql, new postgis" combination in packaging. We could start begging packagers to cover those combos, if the pg_upgrade use case is a killer features (probably is)</div><div><br></div><div>P</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 1:13 AM, Sandro Santilli <span dir="ltr"><<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Sep 05, 2017 at 09:17:36AM +0200, Sandro Santilli wrote:<br>
> On Mon, Sep 04, 2017 at 10:12:00PM +0100, Mark Cave-Ayland wrote:<br>
><br>
> > The other particularly evil thought that occurred to me was do you need<br>
> > to have a real PostGIS 2.3? What if you were to generate a compatibility<br>
> > <a href="http://postgis-2.3.so" rel="noreferrer" target="_blank">postgis-2.3.so</a> with empty stub methods - would that be enough to be able<br>
> > to remove the extension post-upgrade and then install the new version?<br>
><br>
> The ALTER EXTENSION itself makes a single call to a function<br>
> referencing the shared object and already handles an exception<br>
> so it should work.<br>
><br>
> But generating a compatibility layer seems more work than just<br>
> keeping the old signatures in the new code...<br>
<br>
</span>I've conducted an experiment to find out much of a dirty hack we'd<br>
need to provide something working for pg_upgrade.<br>
<br>
1) The tool explicitly tests for the referenced libraries to exist<br>
   and be loadable (touching  a .so does not help, symlinking to<br>
   an arbitrary one does)<br>
<br>
2) The tool ends up using pg_dump/pg_restore but does not have a<br>
   CREATE EXTENSION in the dump !<br>
<br>
<br>
For comparison, this is what you find in the dump created by pg_dump:<br>
<br>
        CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;<br>
<br>
While this is what you find in the dump created by pg_upgrade:<br>
<br>
        -- For binary upgrade, create an empty extension and insert objects into it<br>
        DROP EXTENSION IF EXISTS "postgis";<br>
        SELECT pg_catalog.binary_upgrade_<wbr>create_empty_extension('<wbr>postgis', 'public', false, '2.4.0dev', '{16684}', '{"WHERE NOT (...<br>
<br>
I'm not sure what's the benefit of pg_upgrade, but it's clearly threating<br>
extensions in a different way from pg_dump. Specifically, in a way that<br>
breaks the "EXTENSION will result in easier upgrades" dream...<br>
<br>
To recap (this would be best added in the "upgrade" documentation of postgis):<br>
<br>
 - When upgrading from a PostgreSQL version to another, it's best to<br>
   follow the already documented "hard upgrade" procedure, as it takes<br>
   care of everything.<br>
<br>
 - If willing to use pg_upgrade (I dunno why would you want that) then<br>
   make sure to have the *exact_same* version of PostGIS available in<br>
   the target PostgreSQL version (will need a rebuild)<br>
<div class="HOEnZb"><div class="h5"><br>
--strk;<br>
<br>
<br>
______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a></div></div></blockquote></div><br></div>