2

We've got a number of 4.2.3.2 Greenplum databases that are running PostGIS 1.4. We are trying to get these databases onto a more recent version of Greenplum, such as 4.3.8.1 or the re-released version of 4.3.9.1, but we're running into a mess of issues when attempting to upgrade PostGIS to version 2.0. We've attempted a number of different ways to upgrade the database without compromising data and functions that rely on PostGIS 1.4, but it looks like when we run the gppkg utility with the new PostGIS extensions we only get errors, similar to the following:

gppkg -i postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg 
20160919:13:21:20:024675 gppkg:s-md-pv-gp-01-01:gpadmin-[INFO]:-Starting gppkg with args: -i postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg
20160919:13:21:20:024675 gppkg:s-md-pv-gp-01-01:gpadmin-[CRITICAL]:-gppkg failed. (Reason='__init__() got an unexpected keyword argument 'postupdate'') exiting...

We've also run gppkg passing the -u flag, with similar results:

gppkg -u postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg 
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[INFO]:-Starting gppkg with args: -u postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-WARNING: The process of updating a package includes removing all
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-previous versions of the system objects related to the package. For
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-example, previous versions of shared libraries are removed.
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-After the update process, a database function will fail when it is
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-called if the function references a package file that has been removed.
Do you still want to continue ? Yy|Nn (default=N):
> y
20160919:13:35:59:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[CRITICAL]:-gppkg failed. (Reason='__init__() got an unexpected keyword argument 'postupdate'') exiting...

A major caveat may also be related to the fact that only Greenplum versions 4.2.6.X to 4.2.8.X support both version 1.4 and 2.0 of postGIS. At this point, we're looking for some direction on how to proceed in hopes others may have come up against some of these hurdles.

We've got tickets in with the vendor, Pivotal, but these are not proving fruitful so I'm posting here in hopes the community has some direction they can point me in.

Thanks,

John

2 Answers 2

2
+100

My bet is that the postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg package has a bug and it does not have implemented the postupdate as defined in the Gppkg class. The TAG is optional (SPECFILE_OPTIONAL_TAGS = ... 'postupdate'] ) so it looks like it is calling

Check if the upgrade script ($GPHOME/share/postgresql/contrib/postgis-2.0/postgis_upgrade_20_minor.sql) exists in that location. Package details.

From that specification:

PostUpdate:
10  - Master: "echo 'Please run psql -d mydatabase -f 
$GPHOME/share/postgresql/contrib/postgis-2.0/postgis_upgrade_20_minor.sql 
to finish the update.'"

Also, you may want to try the --clean option

3
  • 1
    That script exists and the --clean flag didn't do the trick either, so I suspect you are correct about the gppkg having a bug contained within it. Thanks for the suggestions though! Sep 28, 2016 at 14:04
  • Seeing as the bounty is coming up for expiration and you were the only response, I'm going to send it your way by default. Better that someone gets it rather then it go to waste. I'll post our upgrade path as I think we've got something workable... just not pretty. Oct 3, 2016 at 18:38
  • Thank you @JohnEisbrener!! At least I did more progress than GP support :p
    – 3manuek
    Oct 3, 2016 at 18:41
0

The upgrade path we have identified is the very definition of kludgy, but it looks to get all the data over with an end result of both an upgraded database and upgraded PostGIS extension. The (admittedly Rube Goldberg-ish) steps are as follows and are required for every database on the server being upgraded containing PostGIS data:

  1. pg_dump all tables containing PostGIS related data for every database on the server
  2. drop all tables containing PostGIS related data (same that were just backed up) for databases that had PostGIS tables in step 1
  3. run unstall_postgis.sql script in $GPHOME/share/postgrestql/contrib against databases that had PostGIS tables in step 1
  4. Uninstall PostGIS 1.0 gppkg (%> gppkg -r postgis-1.0)
  5. Upgrade GreenPlum database via the gpmigrator/gpmigrator_mirrors standard process
  6. Install PostGIS 2.0 gppkg (%> gppkg -i postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg)
  7. run postgis.sql script in $GPHOME/share/postgresql/contrib/postgis-2.0 against each database that had PostGIS tables in step 1
  8. pg_restore all tables exported in step 1

We are also including some steps not listed here on an intermediate server to avoid an in-place upgrade so we have a quick recovery point. The process is a bit cumbersome, but so far testing seems to indicate it is working without any obvious issues.

Hopefully this helps someone out in the future,

John

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.