Question

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

Was it helpful?

Solution 2

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

OTHER TIPS

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

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top