[postgis-devel] Upgrades

Paragon Corporation lr at pcorp.us
Thu Nov 12 13:15:28 PST 2009


Paul,
hmm -- I don't like that policy because it results in broken installs.
There are some errors you can't ignore and shouldn't.

Even more so now than before.  As I said -- with the lets ignore the errors,
you'll have people with bits of there PostGIS 1.5 pointing at bits of 1.4
and 1.3.  Not good.  Keep in mind all these will sort of work since we can
now have multiple PostGIS versions running on a PostgreSQL server instance.

I also don't always like the dump restore especially for large databases,
and that's really the only case where you can safely ignore the errors.  

I have for example a client that has a 800 GB database.  There is no way I'm
going to sell them on a dump restore - especially since they just moved into
their new brank spanking server.  Yes I can work around it and remove the
remnants and stuff, but most people can not.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Thursday, November 12, 2009 3:29 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] Upgrades

I have spend several hours thinking about this stuff, reviewing my old world
and Regina's code in here
(http://trac.osgeo.org/postgis/attachment/ticket/202), and I've decided I
hate it all.

The old way, generating a postgis_upgrade.sql file from the postgis.sql file
is a beauty, I love it, but it conditional stuff gets really ugly and since
1.3 we've added conditional stuff: the upgrade to 1.4 required two new
types, which you would want defined for 1.3 -> 1.4.0 but ignored for 1.4.0
-> 1.4.1.

And the upgrade to 1.5 just piles onto that a couple new types a pile of
operators and a couple operator classes, all of which would require
conditional handling to add them for upgrades from previous major versions
but ignore them for upgrades from minor versions.

And this got me thinking about upgrades in general, and how our current
"best" upgrade advice is not actually any fancy script process but simply:

- create a new database with the new version of postgis in it
- dump from the old database and restore into the new one
- ignore the errors

Works pretty good. And all that conditional mess in the upgrade scripts
could similarly be dropped if the upgrade process was

- run the upgrade script
- ignore the errors

So. Here I am. Mark, I know, favors some kind of fragment approach, and I
thought about that a good while too but never came up with a scheme that
wasn't going to be very very hard to maintain. (It took me half-an-hour just
to remember the issues involved in upgrade. If I needed to keep the issues
in mind every time I altered a function definition in the SQL files, that
could be a bit much.)

So my current suggestion is "worse is better". Move to an "ignore the
errors" upgrade policy and fully document that.

P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel





More information about the postgis-devel mailing list