Greenplum Database 4.3.30.4 Release Notes

Greenplum Database 4.3.30.4 Release Notes

Rev: A01

Updated: November, 2018

Welcome to Pivotal Greenplum Database 4.3.30.4

Greenplum Database is a massively parallel processing (MPP) database server that supports next generation data warehousing and large-scale analytics processing. By automatically partitioning data and running parallel queries, it allows a cluster of servers to operate as a single database supercomputer performing tens or hundreds times faster than a traditional database. It supports SQL, MapReduce parallel processing, and data volumes ranging from hundreds of gigabytes, to hundreds of terabytes.

Important: For Greenplum Database 4.3.16.0 and later, the pgcrypto extension has been updated to package version pv1.3.
  • Previous releases of the pgcrypto extension are not compatible with Greenplum Database 4.3.16.0 and later.
  • The pgcrypto extension package version pv1.3 is not compatible with previous Greenplum Database releases.

For information about the pgcrypto extension package, see Greenplum Database Extensions.

Note: This document contains pertinent release information about Greenplum Database 4.3.30.4. For previous versions of the release notes for Greenplum Database, go to Pivotal Greenplum Database Documentation. For information about Greenplum Database end of life, see the Pivotal Support Lifecycle Policy.
Important: Pivotal Support does not provide support for open source versions of Greenplum Database. Only Pivotal Greenplum Database is supported by Pivotal Support.

Changed Features

Greenplum Database 4.3.30.4 includes these changed features.

  • The Greenplum Database timezone files have been updated. This release includes Internet Assigned Numbers Authority (IANA) Time Zone Database version 2018g.

    Greenplum Database updates its list of available timezones as necessary. The Greenplum Database timezone files are based on the PosgreSQL IANA timezone database files.

  • New Progress DataDirect JDBC drivers are available on Pivotal Network as part of the DataDirect Greenplum Database JDBC Driver 5.1 package. The drivers include these changes.
    • For catalog metadata calls, if all wildcard characters are escaped in search pattern arguments, the driver will push the filter as equivalence rather than LIKE.
    • Kerberos support is now available. Configuration information is available on the Progress web site at Configuring the driver for Kerberos authentication.

    These features are available in Progress DataDirect JDBC driver version 5.1.4.000183 or newer.

  • MADlib 1.15.1 is available. The Greenplum Database Extension for MADlib 1.15.1 contains enhancements and resolves some issues. A summary of the release is available on the MADlib web site, http://madlib.apache.org/. The MADlib release notes are in the MADlib github repository, https://github.com/apache/madlib/blob/master/RELEASE_NOTES.

    See Greenplum Database Tools Compatibility for information about extension compatibility.

Experimental Features

Because Pivotal Greenplum Database is based on the open source Greenplum Database project code, it includes experimental features to allow interested developers to experiment with their use on development systems. Feedback will help drive development of these features, and they may become supported in future versions of the product.

Warning: Experimental features are not recommended or supported for production deployments. These features may change in or be removed from future versions of the product based on further testing and feedback. Moreover, any features that may be visible in the open source code but that are not described in the product documentation should be considered experimental and unsupported for production use.
Greenplum Database 4.3.30.4 includes this experimental feature:
  • Storage plugin framework API. Partners, customers, and OSS developers can develop plugins to use in conjunction with gpbackup and gprestore.

    For information about the storage plugin API, see Backup/Restore Storage Plugin API.

Downloading Greenplum Database

These are the locations of the Greenplum Database software and documentation:

Supported Platforms

Greenplum Database 4.3.30.4 runs on the following platforms:

  • Red Hat Enterprise Linux 64-bit 7.x (See the following Note)
  • Red Hat Enterprise Linux 64-bit 6.x
  • Red Hat Enterprise Linux 64-bit 5.x
  • SuSE Linux Enterprise Server 64-bit 11 SP1, 11 SP2, 11 SP4 (deprecated)
  • Oracle Unbreakable Linux 64-bit 5.5
  • CentOS 64-bit 7.x
  • CentOS 64-bit 6.x
  • CentOS 64-bit 5.x
Note: For the supported Linux operating systems, Pivotal Greenplum Database is supported on system hosts using either AMD or Intel CPUs based on the x86-64 architecture. Pivotal recommends using a homogeneous set of hardware (system hosts) in a Greenplum Database system.
Note: For Greenplum Database that is installed on Red Hat Enterprise Linux 7.x or CentOS 7.x prior to 7.3, an operating system issue might cause Greenplum Database that is running large workloads to hang in the workload. The Greenplum Database issue is caused by Linux kernel bugs.

RHEL 7.3 and CentOS 7.3 resolves the issue.

Note: Support for SuSE Linux Enterprise Server 64-bit 10 SP4 has been dropped for Greenplum Database 4.3.9.0 and later releases.
Greenplum Database 4.3.x supports these Java versions:
  • 8.xxx
  • 7.xxx
  • 6.xxx

Greenplum Database 4.3.30.4 software that runs on Linux systems uses OpenSSL 1.0.2l (with FIPS 2.0.16), cURL 7.54, OpenLDAP 2.4.44, and Python 2.6.9.

Greenplum Database client software that runs on Windows and AIX systems uses OpenSSL 0.9.8zg.

The Greenplum Database s3 external table protocol supports these data sources:

Greenplum Database 4.3.x supports Data Domain Boost on Red Hat Enterprise Linux.

This table lists the versions of Data Domain Boost SDK and DDOS supported by Greenplum Database 4.3.x.

Table 1. Data Domain Boost Compatibility
Greenplum Database Data Domain Boost 1 DDOS
4.3.30.4

4.3.30.3

4.3.30.0

3.3

3.0.0.32

6.1 (all versions)

6.0 (all versions)

5.7 (all versions)

5.6 (all versions)

5.5 (all versions)2

4.3.29.0

4.3.28.0

4.3.27.0

4.3.26.0

4.3.25.1

4.3.25.0

4.3.24.0

4.3.23.0

4.3.22.0

4.3.21.0

4.3.20.0

4.3.19.0

4.3.18.0

4.3.17.1

4.3.17.0

3.3

3.0.0.32

6.0 (all versions)

5.7 (all versions)

5.6 (all versions)

5.5 (all versions)2

4.3.16.1

4.3.16.0

4.3.15.0
4.3.14.1

4.3.14.0

4.3.13.0
4.3.12.0 3.0.0.32 5.7 (all versions)

5.6 (all versions)

5.5 (all versions)2

4.3.11.3

4.3.11.2

4.3.11.1

4.3.10.0
4.3.9.1

4.3.9.0

Note: In addition to the DDOS versions listed in the previous table, Greenplum Database 4.3.9.0 and later supports all minor patch releases (fourth digit releases) later than the certified version.

1The Greenplum Database utilities gpbackup and gprestore support Data Domain DD Boost File System Plugin (BoostFS) v1.1 with DDOS 6.0 or greater.

The gpbackup and gprestore utilities support using Dell EMC Data Domain Boost software with the DD Boost Storage Plugin.

2Support for Data Domain Boost 3.0.0.3 and DDOS 5.5 is deprecated. The DELL EMC end of Primary Support date is December 31, 2017.

Greenplum Database 4.3.30.4 supports Veritas NetBackup:

  • NetBackup Master Server software.
    • NetBackup Master Server Version 7.7 and NetBackup Media Server Version 7.7
    • NetBackup Master Server Version 7.6 and NetBackup Media Server Version 7.6
    • NetBackup Master Server Version 7.5 and NetBackup Media Server Version 7.5
  • NetBackup Client version: 7.1, 7.5, or 7.6.
Note: For NetBackup version 7.5 or 7.6, the client version that is installed and configured on the Greenplum Database hosts must match the NetBackup Server version that stores the Greenplum Database backup.

For NetBackup Client version 7.1, Greenplum Database supports only NetBackup Server Version 7.5.

Greenplum Database uses the NetBackup API (XBSA) to communicate with the NetBackup. Greenplum Database uses SDK version XBSA 1.1.0.

Greenplum Database support for NetBackup Client version 7.1 is deprecated. The NetBackup SDK library files for NetBackup version 7.1 will be removed from the Greenplum Database installation in a future release.

Greenplum Database support on DCA:
  • Greenplum Database 4.3.x, all versions, is supported on DCA V3.
  • Greenplum Database 4.3.x, all versions, is supported on DCA V2, and requires DCA software version 2.1.0.0 or greater due to known DCA software issues in older DCA software versions.

Informatica PowerCenter 10.2 and 9.x are certified with Greenplum Database 4.3.x, all versions.

Note: Greenplum Database 4.3.30.4 does not support the ODBC driver for Cognos Analytics V11.

In the next major release of Greenplum Database, connecting to IBM Cognos software with an ODBC driver will not be supported. Greenplum Database supports connecting to IBM Cognos software with a JDBC driver.

Pivotal recommends that you migrate to a version of IBM Cognos software that supports connectivity to Greenplum Database with a JDBC driver.

Supported Platform Notes

Important: When data loss is not acceptable for a Pivotal Greenplum Database cluster, master and segment mirroring must be enabled in order for the cluster to be supported by Pivotal. Without mirroring, system and data availability is not guaranteed, Pivotal will make best efforts to restore a cluster in this case. For information about master and segment mirroring, see About Redundancy and Failover in the Greenplum Database Administrator Guide.

The following notes describe platform support for Greenplum Database. Please send any questions or comments to Pivotal Support at https://support.pivotal.io.

  • The only file system supported for running Greenplum Database is the XFS file system. All other file systems are explicitly not supported by Pivotal.
  • Greenplum Database is supported on all 1U and 2U commodity servers with local storage. Special purpose hardware that is not commodity may be supported at the full discretion of Pivotal Product Management based on the general similarity of the hardware to commodity servers.
  • Greenplum Database is supported on network or shared storage if the shared storage is presented as a block device to the servers running Greenplum Database and the XFS file system is mounted on the block device. Network file systems are not supported. When using network or shared storage, Greenplum Database mirroring must be used in the same way as with local storage, and no modifications may be made to the mirroring scheme or the recovery scheme of the segments. Other features of the shared storage such as de-duplication and/or replication are not directly supported by Pivotal Greenplum Database, but may be used with support of the storage vendor as long as they do not interfere with the expected operation of Greenplum Database at the discretion of Pivotal.
  • Greenplum Database is supported when running on virtualized systems, as long as the storage is presented as block devices and the XFS file system is mounted for the storage of the segment directories.
  • A minimum of 10-gigabit network is required for a system configuration to be supported by Pivotal.
  • Greenplum Database is supported on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Compute (GCP).
    • AWS - For production workloads, r4.8xlarge and r4.16xlarge instance types with four 12TB ST1 EBS volumes for each segment host are supported.

      Greenplum Database is supported on AWS servers using either Amazon instance store (Amazon uses the volume names ephemeral[0-20]) or Amazon Elastic Block Store (Amazon EBS) storage. If using Amazon instance store storage, the storage should be RAID of Amazon volumes.

      EBS storage is more reliable and provides more features than ephemeral storage but if ephemeral storage is desired, d2.8xlarge is supported for production workloads. With d2.8xlarge and ephemeral storage, use four RAID 0 volumes. Amazon has no provisions to replace a bad drive. If a disk failure occurs, the node with the bad disk must be replaced.

      Pivotal recommends using an Auto Scaling Group (ASG) to provision nodes in AWS. An ASG automatically replaces bad nodes and further automation can be added to automatically recover the Greenplum processes on the new nodes.

      Deployment should be in a Placement Group within a single Availability Zone, and since Amazon recommends using the same instance type in a Placement Group, use a single instance type for all nodes, including the masters.

    • Azure - For production workloads, Standard_E32_v3 and Standard_E64_v3 are supported. Use 12 standard 4 TB disks with Standard_E32_v3 instance type with one segment process per disk. For Standard_E64_v3, use 32 1.5 TB disks with 16 segments per host. This means software RAID 0 is required so that the number of volumes do not exceed the number of segments.
      For Azure deployments, you must also configure the Greenplum Database system to not use port 65330. Add the following line to the sysctl.conf file on all Greenplum Database hosts.
      net.ipv4.ip_local_reserved_ports=65330
    • GCP - For all workloads, n1-standard-8 and n1-highmem-8 are supported which are relatively small instance types. This is because of the disk performance in GCP forces the configuration to have just 2 segments per host but with many hosts to scale. Use pd-standard disks and the size of the disk is recommended to be 6 TB. For performance perspective, use a factor of 8 when determining how many nodes to deploy in GCP, so a 16 segment host cluster in AWS would require 128 nodes in GCP.

  • For Red Hat Enterprise Linux 7.2 or CentOS 7.2, the default systemd setting RemoveIPC=yes removes IPC connections when non-system users logout. This causes the Greenplum Database utility gpinitsystem to fail with semaphore errors. To avoid this issue, see "Setting the Greenplum Recommended OS Parameters" in the Greenplum Database Installation Guide.

Resolved Issues in Greenplum Database 4.3.30.x

The table below lists issues that are now resolved in Pivotal Greenplum Database 4.3.30.x

For issues resolved in prior 4.3 releases, refer to the corresponding release notes. Release notes are available from the Pivotal Greenplum page on Pivotal Network or on the Pivotal Greenplum Database documentation site at Release Notes. A consolidated list of resolved issues for all 4.3 releases is also available on the documentation site.

Table 2. Resolved Issues in 4.3.30.x
Issue Number Category Resolved In Description
29625 Catalog and Metadata 4.3.30.4 The Greenplum Database timezone files were not up to date. For example, on 2017-12-18 Brazil moved the DST date from October 21 to November 04. This was not reflected in the Greenplum Database timezone files.

This issue has been resolved. The timezone files have been updated. See Changed Features.

29616 COPY 4.3.30.4 In some cases, copying CSV data with the COPY...FROM STDIN command caused a Greenplum Database PANIC. The PANIC occurred when Greenplum Database did not correctly handle an error caused by invalid input data.

This issue has been resolved. Now Greenplum Database handles the error correctly and does not generate a PANIC.

29638 VACUUM 4.3.30.3 In some cases when a VACUUM operation was performed on an append-optimized table and other concurrent operations were also being performed on the table, Greenplum Database returned an error stating that the state for a segno from a AO relid was incorrect. The error was cause when Greenplum Database did not correctly track the segment files that had been compacted.

This issue has been resolved. Greenplum Database has improved the tracking of append-optimized segment files during a VACUUM operation.

29635 gpbackup/ gprestore 4.3.30.3 In some cases running a gprestore command with the --on-error-continue option returns an error when creating database metadata. The error is returned when the utility did not correctly handle an error returned by a CREATE SCHEMA command.

This issue has been resolved. Now running the utility with the --on-error-continue option correctly handles errors returned by CREATE SCHEMA commands.

29634 Query Optimizer 4.3.30.3 In some cases, GPORCA generated a Greenplum Database PANIC when executing queries that contain the nullif() function. The PANIC occurred when GPORCA did not return the nullif() result cast as the correct data type.

This issue has been resolved. Now GPORCA returns the function result correctly.

29622 gpcrondump/ gpdbrestore 4.3.30.3 In some cases when the gpdbrestore utility performed a restore operation using Data Domain Boost (DD Boost), the operation failed. The utility did not process backup information for creating database objects when restoring using DD Boost.

This issue has been resolved. Now the utility processes backup information for creating database objects and does not fail.

29611 Query Optimizer 4.3.30.3 For some queries with complex join conditions, GPORCA caused a Greenplum Database PANIC. The PANIC was caused when GPORCA did not correctly determine when possible joins would be cross joins when evaluating join ordering alternatives during query optimization.

This issue has been resolved. GPORCA has improved join order evaluation during query optimization.

29601 gprecoverseg 4.3.30.3 In some cases, the gprecoverseg utility generated a Greenplum Database PANIC during a segment instance recovery operation. The PANIC occurred when the utility generated a SIGSEGV when it did not manage shared memory correctly while a segment instance was being stopped.

This issue has been resolved. The utility has improved the shared memory error handling in the specified situation.

29567 Transaction Management 4.3.30.3 In some cases, a command such as CREATE TABLE did not complete and consumed a large amount of CPU resources. The issue occurred when Greenplum Database did not manage object ID (OID) values correctly when OID value wraparound occurred.

This issue has been resolved. The handling of OID values has been improved for the specified situation.

29428 Query Planner 4.3.30.3 The Greenplum Database legacy optimizer generated a PANIC for some queries that contain a window function when the window function contains a parameter. The query plan generated by the legacy optimizer did not correctly manage parameters when generating subplans for the query.

This issue has been resolved. The legacy optimizer has improved parameter management for the specified type of query.

29360 Query Execution 4.3.30.3 When the server configuration parameter gp_dynamic_partition_pruning was set to off, a query could generate a Greenplum Database PANIC when the query contained an IN clause and the clause contained a subselect. The PANIC was caused when Greenplum Database did not manage the generated IN clause values correctly.

This issue has been resolved. Greenplum Database has improved the handling of IN clause values in the specified situation.

161653513 gpdbrestore 4.3.30.3 The gpdbrestore utility returned an error when the backup that was being restored contained a comment defined on an external table. The error occurred when the utility did not correctly restore the comment.

This issue has been resolved. Now the utility restores comments defined on an external tables.

161635233 gpbackup/ gprestore 4.3.30.3 The gprestore utility returned an error when the restore command specified both the --create-db and --restore-globals options. The failure occurred when the utility attempted to restore roles before creating the database.

This issue has been resolved. Now the utility restores roles after creating the database in the specified situation.

161607786

gpbackup/ gprestore 4.3.30.3 In some cases, when a gprestore command specified the --restore-globals to restore Greenplum Database system objects such as roles, and grant assignments on roles, the utility returned an error stating that a role did not exist. The failure occurred when the utility attempted to execute a GRANT command specifying a role that did not exist.

This issue has been resolved. Now the utility restores roles before executing GRANT commands that specify a role.

161271960 gpbackup/ gprestore 4.3.30.3 In some cases, a restore operation failed when using the gprestore utility with the --include-schema, --exclude-schema, or --exclude-table options. The restore error incorrectly listed a table that was not being restored but already existed in the database. When checking for the existence of tables in the target database, the utility incorrectly checked for tables that were in the backup set but were not being restored.

This issue has been resolved. The gprestore utility has been improved to perform the restore operation without displaying an error in the specified situation.

161074289 gpbackup/ gprestore 4.3.30.3 During a backup operation, the gpbackup utility failed if a user was connected to the database that was being backed up and ran an ALTER ROLE...SET <config_parameter> command to change the default for a server configuration parameter for a role's session.

This issue has been resolved. Now the utility ignores the command during a backup operation and does not fail.

160975618 gpbackup/ gprestore 4.3.30.3 When performing a backup operation, the gpbackup utility failed if the command specified the option --exclude-table or --exclude-schema and the table or schema to be excluded did not exist.

This issue has been resolved. For the specified situation, now the utility does not fail and logs a warning that the table or schema does not exist.

160627949 VACUUM 4.3.30.3 The Greenplum Database autovacuum process incorrectly tested a database that allows connections to manage transaction ID (XID) values to avoid XID wraparound issues. The process should only test databases that do not allow connections (such as the template0 database). In some cases, testing a database that allows connections caused the process to go into an infinite loop.

This issue has been resolved. The autovacuum tests that check databases has been improved to only test databases that do not allow connections.

29594

160864241

gpbackup/ gprestore 4.3.30.0 The gprestore utility failed if the restore operation restored to a database and the name contained upper and lower case characters or special characters.

This issue has been resolved. Now the utility can perform a restore operation to a database with a valid name that contains upper and lower case characters and special characters.

29554 analyzedb 4.3.30.0 The analyzedb utility failed when the schema name or table name for the table being analyzed contains upper and lower case characters or special characters.

This issue has been resolved. The utility has been enhanced to handle the specified type of schema and table names.

29550 DML 4.3.30.0 In some cases, Greenplum Database did not properly insert data into an append-optimized table when a VACUUM operation ran concurrently with the INSERT operation. Greenplum Database did not correctly manage table files on disk that were being vacuumed.

This issue has been resolved. Greenplum Database has improved how append-optimized table disk files are managed in the specified situation.

29545 Query Optimizer 4.3.30.0 For some queries that contain a JOIN and a join column is not defined with an index, GPORCA generated a suboptimal plan that contains an Indexed Nested Loop Join. The unnecessary Index Scan performed by the Indexed Nested Loop Join caused performance issues.

This issue has been resolved. GPORCA has improved predicate checking to ensure Indexed Nested Loop Joins are related to the join conditions.

29544 gpbackup/ gprestore 4.3.30.0 When performing some backup operations, the gpbackup utility failed and returned the error Dependency resolution failed. The error occurred when the utility did not handle dependencies for some database objects correctly.

This issue has been resolved. The utility has improved the handling dependent database objects.

29530 gpdbrestore 4.3.30.0 When restoring database objects with the gpdbrestore utility with an option to restore specific objects, such the -S option to restore a specific schema, the utility did not correctly restore table columns when the column is defined as a serial data type.

This issue has been resolved. Now the utility correctly restores a column that is defined as a serial data type in the specified situation.

29526 Query Planner 4.3.30.0 For some queries that contain a nested JOIN and the inner JOIN uses a SELECT statement, Greenplum Database returned an error. The error was returned when Greenplum Database did not correctly manage the processing of the inner and outer joins.

This issue has been resolved. Greenplum Database has improved the management of joins for the specified type of queries.

29523 gptoolkit 4.3.30.0 The Greenplum Database view gp_toolkit.gp_bloat_expected_pages view might incorrectly report that a root partition table was bloated even though root partition tables did not contain data. This information could cause a user to run a VACUUM FULL operation on the partitioned table when the operation was not required.

The issue was resolved. Now the view excludes root partition tables when reporting possible table bloat. See Update for gp_toolkit.gp_bloat_expected_pages Issue.

29522 Query Optimizer 4.3.30.0 For some queries that contain a LEFT JOIN and UNION ALL, GPORCA incorrectly generated constraints while processing the LEFT JOIN. This caused the query to return incorrect results.

This issue has been resolved. GPORCA has been improved the join processing for the specified type of queries.

29521 Catalog and Metadata 4.3.30.0 In some rare cases, system catalog issues occurred after recovering from a Greenplum Database host shut down, by performing a gprecoverseg followed by a gprecoverseg -r to rebalance primary and mirror segments. The issues occurred during the rebalance operation because gprecoverseg did not properly handle change tracking entries for hint bits.

This issue has been resolved. The utility has been enhanced to properly handle the specified type of change tracking entries.

29519 Resource Queue 4.3.30.0 In some cases, when query execution was controlled by a resource queue and the query triggered a rule that runs an SQL command, Greenplum Database returned the error out of shared memory adding portal increments. The error was returned when the resource queue did not properly handle the SQL executed by the rule.

This issue has been resolved. Management of SQL commands by resource queues has been improved to handle the specified situation.

29504 gpbackup/ gprestore 4.3.30.0 In some cases, a restore operation performed with gprestore failed with the error data line too long.

This issue has been resolved. The maximum length of CSV data supported by Greenplum Database has been increased to 1GB.

29499 Query Optimizer 4.3.30.0 For queries that generate query plans that contain predicates that are inferred from the query predicates, GPORCA might generate suboptimal plans because of the placement of the inferred predicates in the query plan. This caused performance issues for some queries.

This issue has been resolved. The GPORCA algorithm that determines inferred predicates and places them in the query plan has been improved.

29493 Query Execution 4.3.30.0 In some cases when executing a query, Greenplum Database returned an invalid memory alloc request error. The error was generated by Greenplum Database while monitoring the memory used during query execution when the query executed a large number of functions. The number of functions caused a the Greenplum Database to consume a large amount of memory during query execution.

This issue has been resolved. Greenplum Database has enhanced how it monitors query execution memory to consume less memory.

29441 gpperfmon 4.3.30.0 In the query_history table of the gpperfmon database, a date in 1969 was incorrectly recorded in the tsubmit column for ALTER TABLE...SET DISTRIBUTED commands. The command is not a query and was incorrectly recorded in the table.

This issue has been resolved. The commands are no longer recorded in the query_history table.

26829 DDL 4.3.30.0 When creating a partitioned table with the CREATE TABLE command, Greenplum Database generated a PANIC when a SUBPARTITION TEMPLATE clause was not nested in a SUBPARTITION BY clause.

This issue has been resolved. Greenplum Database syntax checking for CREATE TABLE has been enhanced to return an error in the specified situation.

26589 DDL 4.3.30.0 In a database, a DROP SCHEMA operation (without the CASCADE keyword) could succeed while database objects were being created in the schema. This might have created entries in the pg_class and pg_type tables with invalid namespace values.

This issue has been resolved. Locking on schemas has been improved when creating database objects in the schema and when performing a DROP SCHEMA operation on the schema.

160999837 gpbackup/ gprestore 4.3.30.0 The gpbackup utility incorrectly backed up the table definition of external web tables when performing a backup operation. This caused gprestore to fail when attempting to restore the table definition.

This issue has been resolved. Now gpbackup correctly backs up the table definition of up external web tables.

160941596 gpbackup/ gprestore 4.3.30.0 When the gprestore utility performed a restore operation, datatypes that are defined with the storage attribute set to external were incorrectly restored with the storage attribute set to extended.

This issue has been resolved. Now the utility correctly restores datatypes that are defined with the storage attribute set to external.

159838009, 159966889 gpbackup/ gprestore 4.3.30.0 If you performed a restore operation with the gprestore utility and specified a table filtering option such as --include-table to restore a partitioned table, the partitioned table was restored, however the data was not restored.

This issue has been resolved. Now the utility restores the partitioned table and the table data in the specified situation.

159810802 gpbackup/ gprestore 4.3.30.0 If the gpbackup utility encountered a FATAL error during a backup operation, gpbackup_helper processes might not be terminated might continue running on the segment hosts.

This issue has been resolved. Now the processes are terminated on the segment hosts in the specified situation.

159605003 gpbackup/ gprestore 4.3.30.0 If the gpbackup utility encountered a FATAL error during a backup operation, the utility incorrectly displayed the warning [WARNING]: Failed to remove lock file.

This issue has been resolved. The utility does not display the warning in the specified situation.

Known Issues in Greenplum Database 4.3.30.x

This section lists the known issues in Greenplum Database 4.3.30.x. A workaround is provided where applicable.

For known issues discovered in previous 4.3.x releases, see the release notes available from the Pivotal Greenplum page on Pivotal Network or on the Pivotal Greenplum Database documentation site at Release Notes. For known issues discovered in other previous releases, including patch releases to Greenplum Database 4.2.x, 4.1 or 4.0.x, see the corresponding release notes, available from Dell EMC Support Zone

Table 3. All Known Issues in 4.3.30.x
Issue Category Description
29139 DML In some cases for an append-optimized partitioned table, Greenplum Database acquires a ROW EXCLUSIVE lock on all leaf partitions of the table when inserting data directly into one of the leaf partitions of the table. The locks are acquired the first time Greenplum Database performs validation on the leaf partitions. When inserting data into one leaf partition, the locks are not acquired on the other leaf partitions as long as the validation information remains in memory.

The issue does not occur for heap-storage partitioned tables.

29523 gptoolkit An upgrade between minor releases does not update the template0 database, and in some cases, using these views in the gp_toolkit schema might cause issues if you create a database using template0 as the template database after you upgrade to Greenplum Database 5.11.0 or later.
  • The gp_toolkit.gp_bloat_expected_pages view might incorrectly report that a root partition table is bloated even though root partition tables do not contain data if you upgrade from Greenplum Database 4.3.29.0 or earlier.
  • The gp_toolkit.gp_bloat_diag view might return an integer out of range error in some cases if you upgrade from Greenplum Database 4.3.19.0 or earlier.

For example, the issues might occur if you upgrade a Greenplum Database system from 4.3.19.0 or an earlier 5.x release and then run a gprestore operation with the --redirect-db option to create a new database. The utility creates a new database using template0 as the template database.

Workaround: You can update the views in the gp_toolkit schema in the new database. For information about checking and updating gp_toolkit, see Update for gp_toolkit.gp_bloat_expected_pages Issue and Update for gp_toolkit.gp_bloat_diag Issue.

29485 Catalog and Metadata When a session creates temporary objects in a database, Greenplum Database might not the drop temporary objects when the session ends if the session terminates abnormally or is terminated from an administrator command.
29496 gpconfig For a small number of server configuration parameters such as log_min_messages, the command gpconfig -s <config_param> does not display the correct value of the parameter for the segment hosts when the value of the parameter on master is different than the value on the segments.

For parameters with the set classification master, the utility displays the value set on the master for both master and segments (for information about set classifications, see Setting Parameters). For those parameters, the value on the master is passed as part of queries to segment instances. The SQL query that gpconfig runs to display the master and segment parameter values returns the master host value that is passed to the segment as part of the query.

For a few parameters such as log_min_messages, segment instances use the segment host value specified in the postgresql.conf file at start up. The segment value can overridden for the scope of a query.

Workaround: To display the parameter value specified in the postgresql.conf file on the master host and segment hosts, you can specify the gpconfig option --file.

29395 DDL The gpdbrestore or gprestore utility fails when the utility attempts to restore a table from a backup and the table is incorrectly defined with duplicate columns as distribution keys. The issue is caused when the gpcrondump or gpbackup utility backed up a table that is incorrectly defined. The CREATE TABLE AS command could create a table that is incorrectly defined with a distribution policy that contains duplicate columns as distribution keys.
29351 gptransfer The gptransfer utility can copy a data row with a maximum length of 256 MB.
151135629 COPY When the ON SEGMENT clause is specified, the COPY command does not support specifying a SELECT statement in the COPY TO command. However, this command completes successfully, but the files are not created on the segment hosts.
COPY (SELECT * FROM testtbl)
  TO '/tmp/mytst<SEGID>' ON SEGMENT
150625402 Session Management When the server configuration parameter gp_strict_xml_parse is set for a session and the session is idle for longer than gp_vmem_idle_resource_timeout, the value of gp_strict_xml_parse changes back to the value set for the system (or the database if the parameter is set for the database).
29064 Storage: DDL The money datatype accepts out-of-range values as negative values, and no error message is displayed.

Workaround: Use only in-range values for the money datatype (32-bit for Greenplum Database 4.x, or 64-bit for Greenplum Database 5.x). Or, use an alternative datatype such as numeric or decimal.

28947 Access Methods A deadlock might occur on an append-optimized columnar table when a VACUUM operation and an INSERT operation are performed concurrently on the table.

Workaround: If a deadlock condition occurs, terminate the INSERT operation to break the deadlock. To eliminate the possibility of encountering this issue, avoid concurrent VACUUM and INSERT operations.

26675 gpcrondump During the transition from Daylight Saving Time to Standard Time, this sequence of events which might cause a gpcrondump backup operation to fail.

If an initial backup is taken between 1:00AM and 2:00AM Daylight Saving Time, and a second backup is taken between 1:00AM and 2:00AM Standard Time, the second backup might fail if the first backup has a timestamp newer than the second.

Pivotal recommends performing only a single backup between the hours of 1:00AM and 2:00AM on the days when the time changes:
  • November 5, 2017
  • November 4, 2018
  • November 3, 2019

If the failure scenario is encountered, it can be remedied by restarting the backup operation after 2:00AM Standard Time.

146542311 gpload When running the Greenplum Database utility gpload on AIX systems, the utility returns an error if the YAML control file for utility contains a line that specifies the \ (backslash) as the escape character, ESCAPE: '\'. The error states that the \ at the end of a string could not be decoded.

Workaround: To avoid the error, remove the line from the file, or specify the line without a character, ESCAPE:. The \ character is the default escape character. The line is not required in the file.​

142743943 S3 External Tables The s3 protocol might not handle the header row in data files properly in this situation:
  • A readable external table is defined with the s3 protocol and the HEADER option.
  • The external table has been exchanged to be a leaf child table of a partitioned table.

Queries against the partitioned table might return an error.

26591 Query Execution For the Greenplum Database function get_ao_compression_ratio(), specifying a null value or the name of table that contains no rows causes a Greenplum Database PANIC.

Workaround: Specify a non-null value or a table that contains rows.

115746399 Operating System For Greenplum Database that is installed on Red Hat Enterprise Linux 7.x or CentOS 7.x prior to 7.3, an operating system issue might cause Greenplum Database that is running large workloads to hang in the workload. The Greenplum Database issue is caused by Linux kernel bugs.

Workaround: RHEL 7.3 and CentOS 7.3 resolves the issue.

26626 GPHDFS For Greenplum Database external tables, the gphdfs protocol supports Avro files that contain a single top-level schema. Avro files that contain multiple top-level schemas are not supported.
25584 Query Execution In some situations, a running Greenplum Database query cannot be terminated with the functions pg_cancel_backend or pg_terminate_backend.

The functions could not terminate the query due to a blocking fopen of a FIFO file for write.

26249 GPHDFS When reading data from an Avro file, the gphdfs protocol does not support the double quote character (") within string data. The gphdfs protocol uses the double quote as the column delimiter.

Workaround: Before reading data from an Avro file, either remove double quotes that are in string data or replace the character with a different character.

26292 Loaders: gpload The Greenplum Database gpload utility fails on MacOS X El Capitan. The utility script is included with the Greenplum Database Load Tools installer package for Apple OS X greenplum-loaders-version-OSX-i386.bin.
Workaround: Run the python script gpload.py directly. For example, python command displays the gpload help information on the command line.
python gpload.py -h
26128 Loaders: gpload When the YAML control file for the Greenplum Database gpload utility specifies the key LOG_ERRORS: true without the key REUSE TABLES: true, the gpload operation returns only summary information about formatting errors. The formatting errors are deleted from Greenplum Database error logs. When REUSE TABLES: true is not specified, the temporary tables that are used by gpload are dropped after the gpload operation, and the formatting errors are also deleted from the Greenplum Database error logs.

Workaround: Specify the YAML control file key REUSE TABLES: true to retain the temporary tables that are used to load the data. The log information is also retained. You can delete the formatting errors in the Greenplum Database logs with the Greenplum Database function gp_truncate_error_log().

For information about the gpload utility, see the Greenplum Database Utility Guide.

25934

25936

Query Optimizer

Query Planner

For queries that compare data from columns of different character types, for example a join comparing a columns of data types CHAR(n) and VARCHAR(m), the returned results might not be as expected depending the padding added to the data (space characters added after the last non-space character).
For example, this comparison returns false.
select 'A '::char(2) ='A '::text ;
This comparison returns true.
select 'A'::char(2) ='A '::varchar(5) ; 

Workaround: Pivotal recommends specifying character column types to be of data type VARCHAR or TEXT so that comparisons include padding added to the data.

For information about how the character data types CHAR, VARCHAR, and TEXT handle padding added to the data see the CREATE TABLE command in the Greenplum Database Reference Guide.

25737 Catalog and Metadata Greenplum Database does not support the FILTER clause within aggregate expressions.
25754 Management Scripts: expansion The Greenplum Database gpexpand utility fails to create an input file for system expansion if the Greenplum Database system define different TCP/IP port numbers on different hosts for Greenplum Database internal communication.

Workaround: Create the input file manually.

25833 Management Scripts: gpexpand The Greenplum Database utility gpexpand fails when expanding a Greenplum Database system and in the system a database table column name contains a tab character. The utility does not support database names, table names, or column names that contain a tab character.
15835 DDL and Utility Statements For multi-level partitioned tables that have these characteristics:
  • The top level partition is partitioned by range.
  • The lowest level partition (the leaf child partitions) are partitioned by list.
Splitting a subpartition with the ALTER TABLE SPLIT PARTITION command returns an error and rolls back the transaction.
12019 Management Scripts: checkperf When the Greenplum Database gpcheckperf utility is run with the option -f host_file and the host that is running gpcheckperf is listed in host_file, processes that were started gpcheckperf might not be cleaned up after the utility completes.

Workaround: Manually stop the processes that were started by gpcheckperf.

24870 Query Optimizer GPORCA might terminate all sessions if a query attempts to cast to a timestamp a date with year greater than 200,000.
23571 Query Optimizer For queries that contain inequality conditions such as != , < and , >, GPORCA does not consider table indexes when generating a query plan. For those queries, indexes are not used and the query might run slower than expected.
21508 Query Optimizer GPORCA does not support GiST indexes.
20030 Query Optimizer GPORCA does not support partition elimination when the query contains functions that are applied to the partition key.
20360 Query Execution GPORCA does not enforce different access rights in different parts of a partition table. Pivotal recommends that you set the same access privileges for the partitioned table and all its parts (child tables).
20241 Query Optimizer The GPORCA does not consider indices when querying parts/child tables of partitioned tables directly.
25326 Interconnect Setting the Greenplum Database server configuration parameter log_hostname to on Greenplum Database segment hosts causes an Interconnect Error that states that the listeneraddress name or service not known.

The parameter should be set to on only on the Greenplum Database master.

25280 Management Scripts: gpstart/gpstop The Greenplum Database utility gpstop, the utility returns an error if it is run and the system environment variable LANG is set, for example, export LANG=ja_JP.UTF-8.
Workaround: Unset the environment variable LANG before running the gpstop utility. For example:
$ unset LANG
25246 Management Scripts: gpconfig When you set the server configuration parameters gp_email_to and gp_email_from with the Greenplum Database utility gpconfig, the utility removes the single quotes from the values.
$ gpconfig -c gp_email_to -v 'test@example.com'
The improperly set parameter causes Greenplum Database to fail when it is restarted.
Workaround: Enclose the value for gp_email_to or gp_email_from with double quotes.
$ gpconfig -c gp_email_to -v "'test@example.com'"
25168 Locking, Signals, Processes When the server configuration parameter client_min_messages is set to either set to PANIC or FATAL and a PANIC or FATAL level message is encountered, Greenplum Database hangs.

The client_min_messages parameter should not be set a value higher than ERROR.

24588 Management Scripts: gpconfig The Greenplum Database gpconfig utility does not display the correct information for the server configuration parameter gp_enable_gpperfmon. The parameter displays the state of the Greenplum Command Center data collection agents (gpperfmon).

Workaround: The SQL command SHOW displays the correct gp_enable_gpperfmon value.

24031 gphdfs If a readable external table is created with FORMAT 'CSV' and uses the gphdfs protocol, reading a record fails if the record spans multiple lines and the record is stored in multiple HDFS blocks.

Workaround: Remove line separators from within the record so that the record does not span multiple lines.

23824 Authentication In some cases, LDAP client utility tools cannot be used after running the source command:

source $GPHOME/greenplum_path.sh

because the LDAP libraries included with Greenplum Database are not compatible with the LDAP client utility tools that are installed with operating system.

Workaround: The LDAP tools can be used without running the source command in the environment.

23366 Resource Management In Greenplum Database 4.2.7.0 and later, the priority of some running queries, cannot be dynamically adjusted with the gp_adjust_priority() function. The attempt to execute this request might silently fail. The return value of the gp_adjust_priority() call indicates success or failure. If 1 is returned, the request was not successfully executed. If a number greater than 1 is returned, the request was successful. If the request fails, the priority of all running queries are unchanged, they remain as they were before the gp_adjust_priority() call.
23492 Backup and Restore, A backup from a Greenplum Database 4.3.x system that is created with a Greenplum Database back up utility, for example gpcrondump, cannot be restored to a Greenplum Database 4.2.x system with the psql utility or the corresponding restore utility, for example gpdbrestore.
23521 Client Access Methods and Tools Hadoop YARN based on Hadoop 2.2 or later does not work with Greenplum Database.

Workaround: For Hadoop distributions based on Hadoop 2.2 or later that are supported by Greenplum Database, the classpath environment variable and other directory paths defined in $GPHOME/lib/hadoop/hadoop_env.sh must be to be modified so that the paths point to the appropriate JAR files.

20453 Query Planner For SQL queries of either of the following forms:
SELECT columns FROM table WHERE table.column NOT IN subquery;
SELECT columns FROM table WHERE table.column = ALL subquery;
tuples that satisfy both of the following conditions are not included in the result set:
  • table.column is NULL.
  • subquery returns the empty result.
21838 Backup and Restore When restoring sets of tables with the Greenplum Database utility gpdbrestore, the table schemas must be defined in the database. If a table’s schema is not defined in the database, the table is not restored. When performing a full restore, the database schemas are created when the tables are restored.

Workaround: Before restoring a set of tables, create the schemas for the tables in the database.

21129 DDL and Utility Statements SSL is only supported on the master host. It is not supported on segment hosts.
20822 Backup and Restore Special characters such as !, $, #, and @ cannot be used in the password for the Data Domain Boost user when specifying the Data Domain Boost credentials with the gpcrondump options --ddboost-host and --ddboost-user.
18247 DDL and Utility Statements TRUNCATE command does not remove rows from a sub-table of a partitioned table. If you specify a sub-table of a partitioned table with the TRUNCATE command, the command does not remove rows from the sub-table and its child tables.

Workaround: Use the ALTER TABLE command with the TRUNCATE PARTITION clause to remove rows from the sub-table and its child tables.

19705 Loaders: gpload gpload fails on Windows XP with Python 2.6.

Workaround: Install Python 2.5 on the system where gpload is installed.

19493

19464

19426

Backup and Restore The gpcrondump and gpdbrestore utilities do not handle errors returned by DD Boost or Data Domain correctly.
These are two examples:
  • If invalid Data Domain credentials are specified when setting the Data Domain Boost credentials with the gpcrondump utility, the error message does not indicate that invalid credentials were specified.
  • Restoring a Greenplum database from a Data Domain system with gpdbrestore and the --ddboost option indicates success even though segment failures occured during the restore.

Workaround: The errors are logged in the master and segment server backup or restore status and report files. Scan the status and report files to check for error messages.

15692

17192

Backup and Restore Greenplum Database’s implementation of RSA lock box for Data Domain Boost changes backup and restore requirements for customers running SuSE.

The current implementation of the RSA lock box for Data Domain Boost login credential encryption only supports customers running on Red Hat Enterprise Linux.

Workaround: If you run Greenplum Database on SuSE, use NFS as your backup solution. See the Greenplum Database Administrator Guide for information on setting up a NFS backup.

18850 Backup and Restore Data Domain Boost credentials cannot be set up in some environments due to the absence of certain libraries (for example, libstdc++) expected to reside on the platform.

Workaround: Install the missing libraries manually on the system.

18851 Backup and Restore When restoring table data to an existing table with the Greenplum Database utility gpdbrestore, the utility assumes that the database table definition is the same as the table that was backed up. The utility does not check the table definition.

For example, the distribution key for a table is changed after it is backed up. You back up the table, change the table distribution key, truncate the table, and then restore the table data from the backup. Subsequent queries against the table might return unexpected and incorrect results.

Workaround: For the previous example, run the ALTER TABLE command with the REORGANIZE=true clause to redistribute the table data among the Greenplum Database segments. See ALTER TABLE in the Greenplum Database Reference Guide.

18713 Catalog and Metadata Drop language plpgsql cascade results in a loss of gp_toolkit functionality.

Workaround: Reinstall gp_toolkit.

18710 Management Scripts Suite Greenplum Management utilities cannot parse IPv6 IP addresses.

Workaround: Always specify IPv6 hostnames rather than IP addresses

18703 Loaders The bytenum field (byte offset in the load file where the error occurred) in the error log when using gpfdist with data in text format errors is not populated, making it difficult to find the location of an error in the source file.
12468 Management Scripts Suite gpexpand --rollback fails if an error occurs during expansion such that it leaves the database down

gpstart also fails as it detects that expansion is in progress and suggests to run gpexpand --rollback which will not work because the database is down.

Workaround: Run gpstart -m to start the master and then run rollback.

18785 Loaders Running gpload with the --ssl option and the relative path of the source file results in an error that states the source file is missing.

Workaround: Provide the full path in the yaml file or add the loaded data file to the certificate folder.

18414 Loaders Unable to define external tables with fixed width format and empty line delimiter when file size is larger than gpfdist chunk (by default, 32K).
17285 Backup and Restore NFS backup with gpcrondump -c can fail.

In circumstances where you haven't backed up to a local disk before, backups to NFS using gpcrondump with the -c option can fail. On fresh systems where a backup has not been previously invoked there are no dump files to cleanup and the -c flag will have no effect.

Workaround: Do not run gpcrondump with the -c option the first time a backup is invoked from a system.

17837 Upgrade/ Downgrade Major version upgrades internally depend on the gp_toolkit system schema. The alteration or absence of this schema may cause upgrades to error out during preliminary checks.

Workaround: To enable the upgrade process to proceed, you need to reinstall the gp_toolkit schema in all affected databases by applying the SQL file found here: $GPHOME/share/postgresql/gp_toolkit.sql.

17513 Management Scripts Suite Running more than one gpfilespace command concurrently with itself to move either temporary files (--movetempfilespace) or transaction files (--movetransfilespace) to a new filespace can in some circumstances cause OID inconsistencies.

Workaround: Do not run more than one gpfilespace command concurrently with itself. If an OID inconsistency is introduced gpfilespace --movetempfilespace or gpfilespace --movetransfilespace can be used to revert to the default filespace.

17780 DDL/DML: Partitioning ALTER TABLE ADD PARTITION inheritance issue

When performing an ALTER TABLE ADD PARTITION operation, the resulting parts may not correctly inherit the storage properties of the parent table in cases such as adding a default partition or more complex subpartitioning. This issue can be avoided by explicitly dictating the storage properties during the ADD PARTITION invocation. For leaf partitions that are already afflicted, the issue can be rectified through use of EXCHANGE PARTITION.

17795 Management Scripts Suite Under some circumstances, gppkg on SuSE is unable to correctly interpret error messages returned by rpm.

On SuSE, gppkg is unable to operate correctly under circumstances that require a non-trivial interpretation of underlying rpm commands. This includes scenarios that result from overlapping packages, partial installs, and partial uninstalls.

17604 Security A Red Hat Enterprise Linux (RHEL) 6.x security configuration file limits the number of processes that can run on gpadmin.

RHEL 6.x contains a security file (/etc/security/limits.d/90-nproc.conf) that limits available processes running on gpadmin to 1064.

Workaround: Remove this file or increase the processes to 131072.

17334 Management Scripts Suite You may see warning messages that interfere with the operation of management scripts when logging in.

Greenplum recommends that you edit the /etc/motd file and add the warning message to it. This will send the messages to are redirected to stdout and not stderr. You must encode these warning messages in UTF-8 format.

17221 Resource Management Resource queue deadlocks may be encountered if a cursor is associated with a query invoking a function within another function.
17113 Management Scripts Suite Filespaces are inconsistent when the Greenplum database is down.

Filespaces become inconsistent in case of a network failure. Greenplum recommends that processes such as moving a filespace be done in an environment with an uninterrupted power supply.

17189 Loaders: gpfdist gpfdist shows the error “Address already in use” after successfully binding to socket IPv6.

Greenplum supports IPv4 and IPv6. However, gpfdist fails to bind to socket IPv4, and shows the message “Address already in use”, but binds successfully to socket IPv6.

16064 Backup and Restore Restoring a compressed dump with the --ddboost option displays incorrect dump parameter information.

When using gpdbrestore --ddboost to restore a compressed dump, the restore parameters incorrectly show “Restore compressed dump = Off”. This error occurs even if gpdbrestore passes the --gp-c option to use gunzip for in-line de-compression.

15899 Backup and Restore When running gpdbrestore with the list (-L) option, external tables do not appear; this has no functional impact on the restore job.

Upgrading to Greenplum Database 4.3.30.x

The upgrade path supported for this release is Greenplum Database 4.2.x.x to Greenplum Database 4.3.30.x. The minimum recommended upgrade path for this release is from Greenplum Database version 4.2.x.x. If you have an earlier major version of the database, you must first upgrade to version 4.2.x.x.

Prerequisites

Before starting the upgrade process, Pivotal recommends performing the following checks.

  • Verify the health of the Greenplum Database host hardware, and that you verify that the hosts meet the requirements for running Greenplum Database. The Greenplum Database gpcheckperf utility can assist you in confirming the host requirements.
  • If upgrading from Greenplum Database 4.2.x.x, Pivotal recommends running the gpcheckcat utility to check for Greenplum Database catalog inconsistencies.
    Note: If you need to run the gpcheckcat utility, Pivotal recommends running it a few weeks before the upgrade and that you run gpcheckcat during a maintenance period. If necessary, you can resolve any issues found by the utility before the scheduled upgrade.

    The utility is in $GPHOME/bin. Pivotal recommends that Greenplum Database be in restricted mode when you run gpcheckcat utility. See the Greenplum Database Utility Guide for information about the gpcheckcat utility.

    If gpcheckcat reports catalog inconsistencies, you can run gpcheckcat with the -g option to generate SQL scripts to fix the inconsistencies.

    After you run the SQL scripts, run gpcheckcat again. You might need to repeat the process of running gpcheckcat and creating SQL scripts to ensure that there are no inconsistencies. Pivotal recommends that the SQL scripts generated by gpcheckcat be run on a quiescent system. The utility might report false alerts if there is activity on the system.

    Important: If the gpcheckcat utility reports errors, but does not generate a SQL script to fix the errors, contact Pivotal support. Information for contacting Pivotal Support is at https://support.pivotal.io.
  • Ensure that the Linux sed utility is installed on the Greenplum Database hosts. In Greenplum Database releases prior to 4.3.10.0, the Linux ed utility is required on Greenplum Database hosts. The gpinitsystem utility requires the Linux utility.
  • During the migration process from Greenplum Database 4.2.x.x, a backup is made of some files and directories in $MASTER_DATA_DIRECTORY. Pivotal recommends that files and directories that are not used by Greenplum Database be backed up, if necessary, and removed from the $MASTER_DATA_DIRECTORY before migration. For information about the Greenplum Database migration utilities, see the Greenplum Database Utility Guide.
Important: If you intend to use an extension package with Greenplum Database 4.3.30.x, you must install and use a Greenplum Database extension packages (gppkg files and contrib modules) that are built for Greenplum Database 4.3.5.0 or later. For custom modules that were used with Greenplum Database 4.3.4.x and earlier, you must rebuild any modules that were built against the provided C language header files for use with Greenplum Database 4.3.5.0 or later.

If you use the Greenplum Database MADlib extension, Pivotal recommends that you upgrade to the most recent version of MADlib. For MADlib support and upgrade information, refer to the MADlib FAQ. For information on installing the MADlib extension in Greenplum Database, see Greenplum MADlib Extension for Analytics in the Greenplum Database Reference Guide.

If the pgcrypto extension package version pv1.2 or earlier is installed in your system, you must uninstall the pgcrypto extension and install pgcrypto package version pv1.3.

For information about supported versions of Greenplum Database extensions, see Greenplum Database Extensions.

For detailed upgrade procedures and information, see the following sections:

If you are utilizing Data Domain Boost, you have to re-enter your DD Boost credentials after upgrading from Greenplum Database 4.2.x.x to 4.3.x.x as follows:

gpcrondump --ddboost-host ddboost_hostname --ddboost-user ddboost_user
  --ddboost-backupdir backup_directory
Note: If you do not reenter your login credentials after an upgrade, your backup will never start because the Greenplum Database cannot connect to the Data Domain system. You will receive an error advising you to check your login credentials.

Upgrading from 4.3.x to 4.3.30.x

An upgrade from 4.3.x to 4.3.30.x involves stopping Greenplum Database, updating the Greenplum Database software binaries, upgrading and restarting Greenplum Database. If you are using Greenplum Database extension packages there are additional requirements. See Prerequisites in the previous section.

Important: If you are upgrading from Greenplum Database 4.3.x on a Pivotal DCA system, see Upgrading from 4.3.x to 4.3.30.x on Pivotal DCA Systems. This section is for upgrading to Greenplum Database 4.3.30.x on non-DCA systems.
Note: If you have databases that were created with Greenplum Database 4.3.29.0 or an earlier 4.3.x release, upgrade the gp_bloat_expected_pages view in the gp_toolkit schema. For information about the issue and how check a database for the issue, see Update for gp_toolkit.gp_bloat_expected_pages Issue.
Note: If you are upgrading from Greenplum Database 4.3.27.0 or an earlier 4.3.x release and have configured PgBouncer in your Greenplum Database installation, you must migrate to the new PgBouncer when you upgrade Greenplum Database. Refer to Migrating PgBouncer for specific migration instructions.
Note: If you have databases that were created with Greenplum Database 4.3.19.0 or an earlier 4.3.x release, upgrade the gp_bloat_diagfunction and view in the gp_toolkit schema. For information about the issue and how check a database for the issue, see Update for gp_toolkit.gp_bloat_diag Issue.
Note: If you are upgrading from Greenplum Database between 4.3.0 and 4.3.2, run the fix_ao_upgrade.py utility to check Greenplum Database for the upgrade issue and fix the upgrade issue (See step 11). The utility is in this Greenplum Database directory: $GPHOME/share/postgresql/upgrade

For information about the utility, see fix_ao_upgrade.py Utility.

Note: If your database contains append-optimized tables that were converted from Greenplum Database 4.2.x append-only tables, and you are upgrading from a 4.3.x release earlier than 4.3.6.0, run the fix_visimap_owner.sql script to fix a Greenplum Database append-optimized table issue (See step 12). The utility is in this Greenplum Database directory: $GPHOME/share/postgresql/upgrade

For information about the script, see fix_visimap_owner.sql Script.

Note: If the Greenplum Command Center database gpperfmon is installed in your Greenplum Database system, the migration process changes the distribution key of the Greenplum Database log_alert_* tables to the logtime column. The redistribution of the table data might take some time the first time you start Greenplum Database after migration. The change occurs only the first time you start Greenplum Database after a migration.
  1. Log in to your Greenplum Database master host as the Greenplum administrative user:
    $ su - gpadmin
  2. Uninstall the Greenplum Database gNet extension package if it is installed.

    The gNet extension package contains the software for the gphdfs protocol. For Greenplum Database 4.3.1 and later releases, the extension is bundled with Greenplum Database. The files for gphdfs are installed in $GPHOME/lib/hadoop.

  3. Perform a smart shutdown of your current Greenplum Database 4.3.x system (there can be no active connections to the database). This example uses the -a option to disable confirmation prompts:
    $ gpstop -a
  4. Run the installer for 4.3.30.x on the Greenplum Database master host.
    When prompted, choose an installation location in the same base directory as your current installation. For example:
    /usr/local/greenplum-db-4.3.30.4
  5. If your Greenplum Database deployment uses LDAP authentication, manually edit the /usr/local/greenplum-db/greenplum_path.sh file to add the line:
    export LDAPCONF=/etc/openldap/ldap.conf
  6. Edit the environment of the Greenplum Database superuser (gpadmin) and make sure you are sourcing the greenplum_path.sh file for the new installation. For example change the following line in .bashrc or your chosen profile file:
    source /usr/local/greenplum-db-4.3.0.0/greenplum_path.sh

    to:

    source /usr/local/greenplum-db-4.3.30.4/greenplum_path.sh

    Or if you are sourcing a symbolic link (/usr/local/greenplum-db) in your profile files, update the link to point to the newly installed version. For example:

    $ rm /usr/local/greenplum-db
    $ ln -s /usr/local/greenplum-db-4.3.30.4 /usr/local/greenplum-db
  7. Source the environment file you just edited. For example:
    $ source ~/.bashrc
  8. Run the gpseginstall utility to install the 4.3.30.x binaries on all the segment hosts specified in the hostfile. For example:
    $ gpseginstall -f hostfile
  9. Rebuild any modules that were built against the provided C language header files for use with Greenplum Database 4.3.5.0 or later (for example, any shared library files for user-defined functions in $GPHOME/lib). See your operating system documentation and your system administrator for information about rebuilding and compiling modules such as shared libraries.
  10. Use the Greenplum Database gppkg utility to install Greenplum Database extensions. If you were previously using any Greenplum Database extensions such as pgcrypto, PL/R, PL/Java, PL/Perl, and PostGIS, download the corresponding packages from Pivotal Network, and install using this utility. See the Greenplum Database 4.3 Utility Guide for gppkg usage details.
  11. If you are upgrading from Greenplum Database 4.3.27.0 or an earlier 4.3.x release and have configured PgBouncer in your Greenplum Database installation, you must migrate to the new PgBouncer when you upgrade Greenplum Database. Refer to Migrating PgBouncer for specific migration instructions.
  12. After all segment hosts have been upgraded, you can log in as the gpadmin user and restart your Greenplum Database system:
    # su - gpadmin
    $ gpstart
  13. If you are upgrading a version of Greenplum Database between 4.3.0 and 4.3.2, check your Greenplum Database for inconsistencies due to an incorrect conversion of 4.2.x append-only tables to 4.3.x append-optimized tables.
    Important: The Greenplum Database system must be started but should not be running any SQL commands while the utility is running.
    1. Run the fix_ao_upgrade.py utility with the option --report. The following is an example.
      $ $GPHOME/share/postgresql/upgrade/fix_ao_upgrade.py --host=mdw --port=5432 --report
    2. If the utility displays a list of inconsistencies, fix them by running the fix_ao_upgrade.py utility without the --report option.
      $ $GPHOME/share/postgresql/upgrade/fix_ao_upgrade.py --host=mdw --port=5432
    3. (optional) Run the fix_ao_upgrade.py utility with the option --report again. No inconsistencies should be reported.
  14. For databases that contain append-optimized tables that were created from Greenplum Database 4.2.x append-only tables, run the fix_visimap_owner.sql script. The script resolves an issue associated with relations associated with append-optimized tables. For example, this command runs the script on the database testdb.
    $ psql -d testdb1 -f $GPHOME/share/postgresql/upgrade/fix_visimap_owner.sql

    The script displays this prompt that allows you to display changes to the affected relations without performing the operation.

    Dry run, without making any modifications (y/n)?
    • Enter y to list ownership changes that would have been made. The owner of the relation is not changed.
    • Enter n make the ownership changes and display the changes to relation ownership.
    Note: Pivotal recommends that you run the script during low activity period. Heavy workloads do not affect database functionality but might affect performance.
  15. If you are utilizing Data Domain Boost, you have to re-enter your DD Boost credentials after upgrading from Greenplum Database 4.3.x to 4.3.30.x as follows:
    gpcrondump --ddboost-host ddboost_hostname --ddboost-user ddboost_user
      --ddboost-backupdir backup_directory
Note: If you do not reenter your login credentials after an upgrade, your backup will never start because the Greenplum Database cannot connect to the Data Domain system. You will receive an error advising you to check your login credentials.

fix_visimap_owner.sql Script

The SQL script fix_visimap_owner.sql resolves ownership issues related to visimap relations that are associated with append-optimized tables.

When upgrading from Greenplum Database 4.2.x to 4.3.x, the 4.2.x append-only tables are converted to 4.3 append-optimized tables. When upgrading from 4.2.x to Greenplum Database 4.3.x earlier than 4.3.6.0, the upgrade process incorrectly assigned the owner of visimap relations to gpadmin, not the owner of the associated append-optimized table.

If you are migrating to this release Greenplum Database from a 4.3.x release earlier than 4.3.6.0, run this SQL script as the gpadmin superuser to fix the incorrect assignment issue for a database.

$GPHOME/share/postgresql/upgrade/fix_visimap_owner.sql

When you run the script, it temporarily creates two functions that update the visimap relations ownership and displays this message that lets you perform a test run without changing ownership.

Dry run, without making any modifications (y/n)?

If you enter y, the script displays the changes that would have been made. The owner of the relation is not changed.

If you enter n, the script changes the owner of the relations and displays the changes that are made.

Before exiting, the script deletes the functions it created.

Note: If you are migrating from Greenplum Database 4.2.x directly to Greenplum Database 4.3.30.x you do not need to run the fix_visimap_owner.sql script. Also, you can run this script on Greenplum Database 4.3.x earlier than 4.3.6.0 to fix the incorrect ownership assignment of visimap relations.

fix_ao_upgrade.py Utility

The fix_ao_upgrade.py utility checks Greenplum Database for an upgrade issue that is caused when upgrading Greenplum Database 4.2.x to a version of Greenplum Database between 4.3.0 and 4.3.2.

The upgrade process incorrectly converted append-only tables that were in the 4.2.x database to append-optimized tables during an upgrade from Greenplum Database 4.2.x to a Greenplum Database 4.3.x release prior to 4.3.2.1. The incorrect conversion causes append-optimized table inconsistencies in the upgraded Greenplum Database system.

Syntax
fix_ao_upgrade.py {-h master_host | --host=master_host}
     {-p master_port | --port=master_port}
     [-u user | --user=user ]
     [--report] [-v | --verbose] [--help]
Options
-r | --report
Report inconsistencies without making any changes.
-h master_host | --host=master_host
Greenplum Database master hostname or IP address.
-p master_port | --port=master_port
Greenplum Database master port.
-u user | --user=user
User name to connect to Greenplum Database. The user must be a Greenplum Database superuser. Default is gpadmin.
v | --verbose
Verbose output that includes table names.
--help
Show the help message and exit.

If you specify the optional --report option, the utility displays a report of inconsistencies in the Greenplum Database system. No changes to Greenplum Database system are made. If you specify the --verbose option with --report, the table names that are affected by the inconsistencies are included in the output.

Dropping Orphan Tables on Greenplum Database Segments

If you upgraded to Greenplum Database 4.3.6.0 and a user dropped a table, in some cases, the table would be dropped only on the Greenplum Database master, not on the Greenplum Database segments. This created orphan tables on Greenplum Database segments. This issue occurs only with Greenplum Database 4.3.6.0. However, the orphan tables remain in Greenplum Database after upgrading to 4.3.30.x.

For Greenplum Database 4.3.6.2 and later, the installation contains this Python script to check for and drop orphan tables on segments.
$GPHOME/share/postgresql/upgrade/fix_orphan_segment_tables.py
You can run this script on Greenplum Database 4.3.30.x to check for and drop orphan tables.
The script performs these operations:
  • Checks for orphan tables on segments and generates file that contains a list of the orphan tables.
  • Deletes orphan tables specified in a text file.

You run the script as a Greenplum Database administrator. The script attempts to log into Greenplum Database as user who runs the script.

To check all databases in the Greenplum Database instance, run this command on the Greenplum Database master. Specify the port to connect to Greenplum Database.
$GPHOME/share/postgresql/upgrade/fix_orphan_segment_tables.py -p port

To check a single database, specify the option -d database.

The command generates a list of orphan tables in the text file orphan_tables_file_timestamp. You can review the list and, if needed, modify it.

To delete orphan tables on the Greenplum Database segments, run this command on the Greenplum Database master. Specify the port to connect to Greenplum Database and the file containing the orphan tables to delete.
$GPHOME/share/postgresql/upgrade/fix_orphan_segment_tables.py -p port -f orphan_tables_file_timestamp 

The script connects only to the databases required to drop orphan tables.

Note: Pivotal recommends that you run the script during a period of low activity to prevent any issues that might occur due to concurrent drop operations.

Upgrading from 4.3.x to 4.3.30.x on Pivotal DCA Systems

Upgrading Greenplum Database from 4.3.x to 4.3.30.x on a Pivotal DCA system involves stopping Greenplum Database, updating the Greenplum Database software binaries, and restarting Greenplum Database. If you are using Greenplum Extension packages, you must install and use Greenplum Database 4.3.5.0 or later extension packages. If you are using custom modules with the extensions, you must also use modules that were built for use with Greenplum Database 4.3.5.0 or later.

Important: Skip this section if you are not installing Greenplum Database 4.3.30.x on DCA systems. This section is only for installing Greenplum Database 4.3.30.x on DCA systems.
Note: If you have databases that were created with Greenplum Database 4.3.29.0 or an earlier 4.3.x release, upgrade the gp_bloat_expected_pages view in the gp_toolkit schema. For information about the issue and how check a database for the issue, see Update for gp_toolkit.gp_bloat_expected_pages Issue.
Note: If you are upgrading from Greenplum Database 4.3.27.0 or an earlier 4.3.x release and have configured PgBouncer in your Greenplum Database installation, you must migrate to the new PgBouncer when you upgrade Greenplum Database. Refer to Migrating PgBouncer for specific migration instructions.
Note: If you have databases that were created with Greenplum Database 4.3.19.0 or an earlier 4.3.x release, upgrade the gp_bloat_diagfunction and view in the gp_toolkit schema. For information about the issue and how check a database for the issue, see Update for gp_toolkit.gp_bloat_diag Issue.
Note: If you are upgrading from Greenplum Database between 4.3.0 and 4.3.2, run the fix_ao_upgrade.py utility to check Greenplum Database for the upgrade issue and fix the upgrade issue (See step 8). The utility is in this Greenplum Database directory: $GPHOME/share/postgresql/upgrade

For information about the utility, see fix_ao_upgrade.py Utility.

  1. Log in to your Greenplum Database master host as the Greenplum administrative user (gpadmin):
    # su - gpadmin
  2. Download or copy the installer file to the Greenplum Database master host.
  3. Uninstall the Greenplum Database gNet extension package if it is installed. For information about uninstalling a Greenplum Database extension package, see gppkg in the Greenplum Database Utility Guide.

    The gNet extension package contains the software for the gphdfs protocol. For Greenplum Database 4.3.1 and later releases, the extension is bundled with Greenplum Database. The files for gphdfs are installed in $GPHOME/lib/hadoop.

  4. Perform a smart shutdown of your current Greenplum Database 4.3.x system (there can be no active connections to the database). This example uses the -a option to disable confirmation prompts:
    $ gpstop -a
  5. As root, run the Pivotal DCA installer for 4.3.30.x on the Greenplum Database master host and specify the file hostfile that lists all hosts in the cluster. If necessary, copy hostfile to the directory containing the installer before running the installer.

    This example command runs the installer for Greenplum Database 4.3.30.4 for Redhat Enterprise Linux 5.x.

    # ./greenplum-db-appliance-4.3.30.4-build-1-RHEL5-x86_64.bin hostfile

    The file hostfile is a text file that lists all hosts in the cluster, one host name per line.

  6. Install Greenplum Database extension packages. For information about installing a Greenplum Database extension package, see gppkg in the Greenplum Database Utility Guide.
    Important: Rebuild any modules that were built against the provided C language header files for use with Greenplum Database 4.3.5.0 or later (for example, any shared library files for user-defined functions in $GPHOME/lib). See your operating system documentation and your system administrator for information about rebuilding and compiling modules such as shared libraries.
  7. If you are upgrading from Greenplum Database 4.3.27.0 or an earlier 4.3.x release and have configured PgBouncer in your Greenplum Database installation, you must migrate to the new PgBouncer when you upgrade Greenplum Database. Refer to Migrating PgBouncer for specific migration instructions.
  8. After all segment hosts have been upgraded, you can log in as the gpadmin user and restart your Greenplum Database system:
    # su - gpadmin
    $ gpstart
  9. If you are upgrading a version of Greenplum Database between 4.3.0 and 4.3.2, check your Greenplum Database for inconsistencies due to an incorrect conversion of 4.2.x append-only tables to 4.3.x append-optimized tables.
    Important: The Greenplum Database system must be started but should not be running any SQL commands while the utility is running.
    1. Run the fix_ao_upgrade.py utility with the option --report. The following is an example.
      $ $GPHOME/share/postgresql/upgrade/fix_ao_upgrade.py --host=mdw --port=5432 --report
    2. If the utility displays a list of inconsistencies, fix them by running the fix_ao_upgrade.py utility without the --report option.
      $ $GPHOME/share/postgresql/upgrade/fix_ao_upgrade.py --host=mdw --port=5432
    3. (optional) Run the fix_ao_upgrade.py utility with the option --report again. No inconsistencies should be reported.
  10. If you are utilizing Data Domain Boost, you have to re-enter your DD Boost credentials after upgrading from Greenplum Database 4.3.x to 4.3.30.x as follows:
    gpcrondump --ddboost-host ddboost_hostname --ddboost-user ddboost_user
      --ddboost-backupdir backup_directory
Note: If you do not reenter your login credentials after an upgrade, your backup will never start because the Greenplum Database cannot connect to the Data Domain system. You will receive an error advising you to check your login credentials.

Upgrading from 4.2.x.x to 4.3.30.x

This section describes how you can upgrade from Greenplum Database 4.2.x.x or later to Greenplum Database 4.3.30.x. For users running versions prior to 4.2.x.x of Greenplum Database, see the following:

Planning Your Upgrade

Before you begin your upgrade, make sure the master and all segments (data directories and filespace) have at least 2GB of free space.

Prior to upgrading your database, Pivotal recommends that you run a pre-upgrade check to verify your database is healthy.

You can perform a pre-upgrade check by executing the gpmigrator (_mirror) utility with the --check-only option.

For example:

source $new_gphome/greenplum_path.sh; 
gpmigrator_mirror --check-only $old_gphome $new_gphome
Note: Performing a pre-upgrade check of your database with the gpmigrator (_mirror) utility should done during a database maintenance period. When the utility checks the database catalog, users cannot access the database.
Important: If you intend to use an extension packages with Greenplum Database 4.3.5.0 or later, you must install and use a Greenplum Database extension packages (gppkg files and contrib modules) that are built for Greenplum Database 4.3.5.0 or later. For custom modules that were used with Greenplum Database 4.3.4.x and earlier, you must rebuild any modules that were built against the provided C language header files for use with Greenplum Database 4.3.5.0 or later.

Migrating a Greenplum Database That Contains Append-Only Tables

The migration process converts append-only tables that are in a Greenplum Database to append-optimized tables. For a database that contains a large number of append-only tables, the conversion to append-optimized tables might take a considerable amount of time. Pivotal supplies a user-defined function that can help estimate the time required to migrate from Greenplum Database 4.2.x to 4.3.x. For information about the user-defined function, estimate_42_to_43_migrate_time.pdf.

Append-optimized tables are introduced in Greenplum Database 4.3.0. For information about append-optimized tables, see the release notes for Greenplum Database 4.3.0.

Upgrade Procedure

This section divides the upgrade into the following phases: pre-upgrade preparation, software installation, upgrade execution, and post-upgrade tasks.

We have also provided you with an Upgrade Checklist that summarizes this procedure.

Important: Carefully evaluate each section and perform all required and conditional steps. Failing to perform any of these steps can result in an aborted upgrade, placing your system in an unusable or even unrecoverable state.
Pre-Upgrade Preparation (on your 4.2.x system)

Perform these steps on your current 4.2.x Greenplum Database system. This procedure is performed from your Greenplum master host and should be executed by the Greenplum superuser (gpadmin).

  1. Log in to the Greenplum Database master as the gpadmin user:
    # su - gpadmin
  2. (optional) Vacuum all databases prior to upgrade. For example:
    $ vacuumdb database_name
  3. (optional) Clean out old server log files from your master and segment data directories. For example, to remove log files from 2011 from your segment hosts:
    $ gpssh -f seg_host_file -e 'rm /gpdata/*/gp*/pg_log/gpdb-2011-*.csv'

    Running VACUUM and cleaning out old logs files is not required, but it will reduce the size of Greenplum Database files to be backed up and migrated.

  4. Run gpstate to check for failed segments.
    $ gpstate
  5. If you have failed segments, you must recover them using gprecoverseg before you can upgrade.
    $ gprecoverseg

    Note: It might be necessary to restart the database if the preferred role does not match the current role; for example, if a primary segment is acting as a mirror segment or a mirror segment is acting as a primary segment.

  6. Copy or preserve any additional folders or files (such as backup folders) that you have added in the Greenplum data directories or $GPHOME directory. Only files or folders strictly related to Greenplum Database operations are preserved by the migration utility.
Install the Greenplum Database 4.3 Software Binaries (non-DCA)
Important: If you are installing Greenplum Database 4.3 on a Pivotal DCA system, see Install the Greenplum Database 4.3 Software Binaries on DCA Systems. This section is for installing Greenplum Database 4.3 on non-DCA systems.
  1. Download or copy the installer file to the Greenplum Database master host.
  2. Unzip the installer file. For example:
    # unzip greenplum-db-4.3.30.4-PLATFORM.zip
  3. Launch the installer using bash. For example:
    # /bin/bash greenplum-db-4.3.30.4-PLATFORM.bin
  4. The installer will prompt you to accept the Greenplum Database license agreement. Type yes to accept the license agreement.
  5. The installer will prompt you to provide an installation path. Press ENTER to accept the default install path (for example: /usr/local/greenplum-db-4.3.30.4), or enter an absolute path to an install location. You must have write permissions to the location you specify.
  6. The installer installs the Greenplum Database software and creates a greenplum-db symbolic link one directory level above your version-specific Greenplum installation directory. The symbolic link is used to facilitate patch maintenance and upgrades between versions. The installed location is referred to as $GPHOME.
  7. Source the path file from your new 4.3.30.x installation. This example changes to the gpadmin user before sourcing the file:
    # su - gpadmin
    $ source /usr/local/greenplum-db-4.3.30.4/greenplum_path.sh
  8. Run the gpseginstall utility to install the 4.3.30.x binaries on all the segment hosts specified in the hostfile. For example:
    $ gpseginstall -f hostfile
Install the Greenplum Database 4.3 Software Binaries on DCA Systems
Important: Skip this section if you are not installing Greenplum Database 4.3 on DCA systems. This section is only for installing Greenplum Database 4.3 on DCA systems.
  1. Download or copy the installer file to the Greenplum Database master host.
  2. As root, run the Pivotal DCA installer for 4.3.30.x on the Greenplum Database master host and specify the file hostfile that lists all hosts in the cluster. If necessary, copy hostfile to the directory containing the installer before running the installer.

    This example command runs the installer for Greenplum Database 4.3.30.4.

    # ./greenplum-db-appliance-4.3.30.4-build-1-RHEL5-x86_64.bin hostfile

    The file hostfile is a text file that lists all hosts in the cluster, one host name per line.

Upgrade Execution

During upgrade, all client connections to the master will be locked out. Inform all database users of the upgrade and lockout time frame. From this point onward, users should not be allowed on the system until the upgrade is complete.

  1. As gpadmin, source the path file from your old 4.2.x.x installation. For example:
    $ source /usr/local/greenplum-db-4.2.8.1/greenplum_path.sh

    On a DCA system, the path to the might be similar to /usr/local/GP-4.2.8.1/greenplum_path.sh depending on the installed version.

  2. (optional but strongly recommended) Back up all databases in your Greenplum Database system using gpcrondump. See the Greenplum Database Administrator Guide for more information on how to do backups using gpcrondump. Make sure to secure your backup files in a location outside of your Greenplum data directories.
  3. If your system has a standby master host configured, remove the standby master from your system configuration. For example:
    $ gpinitstandby -r
  4. Perform a clean shutdown of your current Greenplum Database 4.2.x.x system. This example uses the -a option to disable confirmation prompts:
    $ gpstop -a
  5. Source the path file from your new 4.3.30.x installation. For example:
    $ source /usr/local/greenplum-db-4.3.30.4/greenplum_path.sh

    On a DCA system, the path to the file would be similar to /usr/local/GP-4.3.30.4/greenplum_path.sh.

  6. Update the Greenplum Database environment so it is referencing your new 4.3.30.x installation.
    1. For example, update the greenplum-db symbolic link on the master and standby master to point to the new 4.3.30.4 installation directory. For example (as root):
      # rm -rf /usr/local/greenplum-db
      # ln -s /usr/local/greenplum-db-4.3.30.4 /usr/local/greenplum-db
      # chown -R gpadmin /usr/local/greenplum-db
      On a DCA system, the ln command would specify the install directory created by the DCA installer. For example:
      # ln -s /usr/local/GP-4.3.30.4 /usr/local/greenplum-db
    2. Using gpssh, also update the greenplum-db symbolic link on all of your segment hosts. For example (as root):
      # gpssh -f segment_hosts_file
      => rm -rf /usr/local/greenplum-db
      => ln -s /usr/local/greenplum-db-4.3.30.4 /usr/local/greenplum-db
      => chown -R gpadmin /usr/local/greenplum-db
      => exit
      On a DCA system, the ln command would specify the install directory created by the DCA installer. For example:
      => ln -s /usr/local/GP-4.3.30.4 /usr/local/greenplum-db
  7. (optional but recommended) Prior to running the migration, perform a pre-upgrade check to verify that your database is healthy by executing the 4.3.4 version of the migration utility with the --check-only option. The command is run as gpadmin. This example runs the gpmigrator_mirror utility as gpadmin:
    $ gpmigrator_mirror --check-only 
       /usr/local/greenplum-db-4.2.6.3 
       /usr/local/greenplum-db-4.3.30.4

    On a DCA system, the old GPHOME location might be similar to /usr/local/GP-4.2.8.1 (depending on the old installed version) and the new GPHOME location would be similar to /usr/local/GP-4.3.30.4.

  8. As gpadmin, run the 4.3.30.4 version of the migration utility specifying your old and new GPHOME locations. If your system has mirrors, use gpmigrator_mirror. If your system does not have mirrors, use gpmigrator. For example on a system with mirrors:
    $ gpmigrator_mirror /usr/local/greenplum-db-4.2.6.3 
       /usr/local/greenplum-db-4.3.30.4

    On a DCA system, the old GPHOME location might be similar to /usr/local/GP-4.2.8.1 (depending on the old installed version) and the new GPHOME location would be similar to /usr/local/GP-4.3.30.4.

    Note: If the migration does not complete successfully, contact Customer Support (see Troubleshooting a Failed Upgrade ).
  9. The migration can take a while to complete. After the migration utility has completed successfully, the Greenplum Database 4.3.30.x system will be running and accepting connections.
    Note: After the migration utility has completed, the resynchronization of the mirror segments with the primary segments continues. Even though the system is running, the mirrors are not active until the resynchronization is complete.
Post-Upgrade (on your 4.3.30.x system)
  1. If your system had a standby master host configured, reinitialize your standby master using gpinitstandby:
    $ gpinitstandby -s standby_hostname
  2. If your system uses external tables with gpfdist, stop all gpfdist processes on your ETL servers and reinstall gpfdist using the compatible Greenplum Database 4.3.x Load Tools package. Application Packages are available from the Pivotal Greenplum page on Pivotal Network. For information about gpfdist, see the Greenplum Database 4.3 Administrator Guide.
  3. Rebuild any modules that were built against the provided C language header files for use with Greenplum Database 4.3.5.0 or later. (for example, any shared library files for user-defined functions in $GPHOME/lib). See your operating system documentation and your system administrator for information about rebuilding and compiling modules such as shared libraries.
  4. Use the Greenplum Database gppkg utility to install Greenplum Database extensions. If you were previously using any Greenplum Database extensions such as pgcrypto, PL/R, PL/Java, PL/Perl, and PostGIS, download the corresponding packages from Pivotal Network, and install using this utility. See the Greenplum Database Utility Guide for gppkg usage details.
  5. If you are upgrading from Greenplum Database 4.3.27.0 or an earlier 4.3.x release and have configured PgBouncer in your Greenplum Database installation, you must migrate to the new PgBouncer when you upgrade Greenplum Database. Refer to Migrating PgBouncer for specific migration instructions.
  6. If you want to utilize the Greenplum Command Center management tool, install the latest Command Center Console and update your environment variable to point to the latest Command Center binaries (source the gpperfmon_path.sh file from your new installation). See the Greenplum Command Center documentation for information about installing and configuring Greenplum Command Center.
    Note: The Greenplum Command Center management tool replaces Greenplum Performance Monitor.

    Command Center Console packages are available from the Pivotal Greenplum page on Pivotal Network.

  7. (optional) Check the status of Greenplum Database. For example, you can run the Greenplum Database utility gpstate to display status information of a running Greenplum Database.
    $ gpstate
  8. Inform all database users of the completed upgrade. Tell users to update their environment to source the Greenplum Database 4.3.30.4 installation (if necessary).

Upgrade Checklist

This checklist provides a quick overview of all the steps required for an upgrade from 4.2.x.x to 4.3.30.x. Detailed upgrade instructions are provided in Upgrading from 4.2.x.x to 4.3.30.x.

Pre-Upgrade Preparation (on your current system)

* 4.2.x.x system is up and available
Log in to your master host as the gpadmin user (your Greenplum superuser).
(Optional) Run VACUUM on all databases.
(Optional) Remove old server log files from pg_log in your master and segment data directories.
Check for and recover any failed segments (gpstate, gprecoverseg).
Copy or preserve any additional folders or files (such as backup folders).
Install the Greenplum Database 4.3 binaries on all Greenplum hosts.
Inform all database users of the upgrade and lockout time frame.

Upgrade Execution

* The system will be locked down to all user activity during the upgrade process
Backup your current databases.
Remove the standby master (gpinitstandby -r).
Do a clean shutdown of your current system (gpstop).
Update your environment to source the new Greenplum Database 4.3.x installation.
Run the upgrade utility (gpmigrator_mirror if you have mirrors, gpmigrator if you do not).
After the upgrade process finishes successfully, your 4.3.x system will be up and running.

Post-Upgrade (on your 4.3 system)

* The 4.3.x.x system is up
Reinitialize your standby master host (gpinitstandby).
Upgrade gpfdist on all of your ETL hosts.
Rebuild any custom modules against your 4.3.x installation.
Download and install any Greenplum Database extensions.
(Optional) Install the latest Greenplum Command Center and update your environment to point to the latest Command Center binaries.
Inform all database users of the completed upgrade.

For Users Running Greenplum Database 4.1.x.x

Users on a release prior to 4.1.x.x cannot upgrade directly to 4.3.30.x.

  1. Upgrade from your current release to 4.2.x.x (follow the upgrade instructions in the latest Greenplum Database 4.2.x.x release notes available at Pivotal Documentation).
  2. Follow the upgrade instructions in these release notes for Upgrading from 4.2.x.x to 4.3.30.x.

For Users Running Greenplum Database 4.0.x.x

Users on a release prior to 4.1.x.x cannot upgrade directly to 4.3.30.x.

  1. Upgrade from your current release to 4.1.x.x (follow the upgrade instructions in the latest Greenplum Database 4.1.x.x release notes available on Dell EMC Support Zone).
  2. Upgrade from the current release to 4.2.x.x (follow the upgrade instructions in the latest Greenplum Database 4.2.x.x release notes available at Pivotal Documentation).
  3. Follow the upgrade instructions in these release notes for Upgrading from 4.2.x.x to 4.3.30.x.

For Users Running Greenplum Database 3.3.x.x

Users on a release prior to 4.0.x.x cannot upgrade directly to 4.3.30.x.

  1. Upgrade from your current release to the latest 4.0.x.x release (follow the upgrade instructions in the latest Greenplum Database 4.0.x.x release notes available on Dell EMC Support Zone).
  2. Upgrade the 4.0.x.x release to the latest 4.1.x.x release (follow the upgrade instructions in the latest Greenplum Database 4.1.x.x release notes available on Dell EMC Support Zone).
  3. Upgrade from the 4.1.1 release to the latest 4.2.x.x release (follow the upgrade instructions in the latest Greenplum Database 4.2.x.x release notes available at Pivotal Documentation).
  4. Follow the upgrade instructions in these release notes for Upgrading from 4.2.x.x to 4.3.30.x.

Troubleshooting a Failed Upgrade

If you experience issues during the migration process and have active entitlements for Greenplum Database that were purchased through Pivotal, contact Pivotal Support. Information for contacting Pivotal Support is at https://support.pivotal.io.

Be prepared to provide the following information:

  • A completed Upgrade Procedure.
  • Log output from gpmigrator_mirror and gpcheckcat (located in ~/gpAdminLogs)

Update for gp_toolkit.gp_bloat_expected_pages Issue

In Greenplum Database 4.3.29.0 and earlier 4.3.x releases, the Greenplum Database view gp_toolkit.gp_bloat_expected_pages view might incorrectly report that a root partition table is bloated even though root partition tables do not contain data. This information could cause a user to run a VACUUM FULL operation on the partitioned table when the operation was not required. The issue was resolved in Greenplum Database 4.3.30.0 (resolved issue 29523) .

When updating Greenplum Database, the gp_toolkit.gp_bloat_expected_pages function must be updated in databases created with a Greenplum Database 4.3.29.0 or earlier 4.3.x release. This issue has been fixed in databases created with Greenplum Database 4.3.30.0 and later.

To check whether the gp_toolkit.gp_bloat_expected_pages view in a database requires an update, run the psql command \d+ to display the view definition.

\d+ gp_toolkit.gp_bloat_expected_pages
The updated view definition contains this predicate.
AND NOT EXISTS
( SELECT parrelid
     FROM pg_partition
     WHERE parrelid = pgc.oid )

Perform the following steps as the gpadmin user to update the view on each database that was created with Greenplum Database 5.11.0 or an earlier 5.x release.

  1. Copy the script into a text file on the Greenplum Database master.
  2. Run the script on each database that requires the update.
    This example updates gp_toolkit.gp_bloat_expected_pages view in the database mytest and assumes that the script is in the gp_bloat_expected_pages in the gpadmin home directory.
    psql -f /home/gpadmin/gp_bloat_expected_pages.sql -d mytest

Run the script during a low activity period. Running the script during a high activity period does not affect database functionality but might affect performance.

Script to Update gp_toolkit.gp_bloat_expected_pages View

BEGIN;
CREATE OR REPLACE VIEW gp_toolkit.gp_bloat_expected_pages
AS
    SELECT
      btdrelid,
      btdrelpages,
       CASE WHEN btdexppages < numsegments
          THEN numsegments
          ELSE btdexppages
        END as btdexppages
    FROM
    ( SELECT
        oid as btdrelid,
        pgc.relpages as btdrelpages,
        CEIL((pgc.reltuples * (25 + width))::numeric / current_setting('block_size')::numeric) AS btdexppages,
        (SELECT numsegments FROM gp_toolkit.__gp_number_of_segments) AS numsegments
        FROM
        ( SELECT pgc.oid, pgc.reltuples, pgc.relpages
            FROM pg_class pgc
            WHERE NOT EXISTS
            ( SELECT iaooid
                FROM gp_toolkit.__gp_is_append_only
                WHERE iaooid = pgc.oid AND iaotype = 't' )
            AND NOT EXISTS
            ( SELECT parrelid
                FROM pg_partition
                WHERE parrelid = pgc.oid )) AS pgc
        LEFT OUTER JOIN
          ( SELECT  starelid, SUM(stawidth * (1.0 - stanullfrac)) AS width
              FROM pg_statistic pgs
              GROUP BY 1) AS btwcols
        ON pgc.oid = btwcols.starelid
        WHERE starelid IS NOT NULL) AS subq;

GRANT SELECT ON TABLE gp_toolkit.gp_bloat_expected_pages TO public;
COMMIT;

Update for gp_toolkit.gp_bloat_diag Issue

In Greenplum Database 4.3.19.0 or an earlier 4.3.x release, Greenplum Database returned an integer out of range error in some cases when performing a query against the gp_toolkit.gp_bloat_diag view. The issue was resolved in Greenplum Database 4.3.20.0 (resolved issue 26518) .

When updating Greenplum Database, the gp_toolkit.gp_bloat_diag function and view must be updated in databases created with a Greenplum Database 4.3.19.0 or an earlier 4.3.x release. This issue has been fixed in databases created with Greenplum Database 4.3.20.0 and later.

To check whether the gp_toolkit.gp_bloat_diag function and view in a database requires an update, run the psql command \df to display information about the gp_toolkit.gp_bloat_diag function.

\df gp_toolkit.gp_bloat_diag

If the data type for btdexppages is integer, an update is required. If the data type is numeric an update is not required. In this example, the btdexppages data type is integer and requires an update.

List of functions
-[ RECORD 1 ]-------+------------------------------------------------------------------------------------------------
Schema              | gp_toolkit
Name                | gp_bloat_diag
Result data type    | record
Argument data types | btdrelpages integer, btdexppages integer, aotable boolean, OUT bltidx integer, OUT bltdiag text
Type                | normal

Run the following script to update the function and view to fix the issue on each database that was created with Greenplum Database 4.3.19.0 or an earlier 4.3.x release.

As the gpadmin user, follow these steps.

  1. Copy the script into a text file on the Greenplum Database master.
  2. Run the script on each database that requires the update.
    This example updates gp_toolkit.gp_bloat_diag function and view in the database mytest and assumes that the script is in the update_bloat_diag.sql in the gpadmin home directory.
    psql -f /home/gpadmin/update_bloat_diag.sql -d mytest

Run the script during a low activity period. Running the script during a high activity period does not affect database functionality but might affect performance.

Script to Update gp_toolkit.gp_bloat_diag Function and View
BEGIN;
CREATE OR REPLACE FUNCTION gp_toolkit.gp_bloat_diag(btdrelpages int, btdexppages numeric, aotable bool,
    OUT bltidx int, OUT bltdiag text)
AS
$$
    SELECT
        bloatidx,
        CASE
            WHEN bloatidx = 0
                THEN 'no bloat detected'::text
            WHEN bloatidx = 1
                THEN 'moderate amount of bloat suspected'::text
            WHEN bloatidx = 2
                THEN 'significant amount of bloat suspected'::text
            WHEN bloatidx = -1
                THEN 'diagnosis inconclusive or no bloat suspected'::text
        END AS bloatdiag
    FROM
    (
        SELECT
            CASE
                WHEN $3 = 't' THEN 0
                WHEN $1 < 10 AND $2 = 0 THEN -1
                WHEN $2 = 0 THEN 2
                WHEN $1 < $2 THEN 0
                WHEN ($1/$2)::numeric > 10 THEN 2
                WHEN ($1/$2)::numeric > 3 THEN 1
                ELSE -1
            END AS bloatidx
    ) AS bloatmapping

$$
LANGUAGE SQL READS SQL DATA;

GRANT EXECUTE ON FUNCTION gp_toolkit.gp_bloat_diag(int, numeric, bool, OUT int, OUT text) TO public;

CREATE OR REPLACE VIEW gp_toolkit.gp_bloat_diag
AS
    SELECT
        btdrelid AS bdirelid,
        fnnspname AS bdinspname,
        fnrelname AS bdirelname,
        btdrelpages AS bdirelpages,
        btdexppages AS bdiexppages,
        bltdiag(bd) AS bdidiag
    FROM
    (
        SELECT
            fn.*, beg.*,
            gp_toolkit.gp_bloat_diag(btdrelpages::int, btdexppages::numeric, iao.iaotype::bool) AS bd
        FROM
            gp_toolkit.gp_bloat_expected_pages beg,
            pg_catalog.pg_class pgc,
            gp_toolkit.__gp_fullname fn,
            gp_toolkit.__gp_is_append_only iao

        WHERE beg.btdrelid = pgc.oid
            AND pgc.oid = fn.fnoid
            AND iao.iaooid = pgc.oid
    ) as bloatsummary
    WHERE bltidx(bd) > 0;

GRANT SELECT ON TABLE gp_toolkit.gp_bloat_diag TO public;
COMMIT;

Greenplum Database Tools Compatibility

Client Tools

Greenplum releases a number of client tool packages on various platforms that can be used to connect to Greenplum Database and the Greenplum Command Center management tool. The following table describes the compatibility of these packages with this Greenplum Database release.

Tool packages are available from the Pivotal Greenplum page on Pivotal Network.

Table 4. Greenplum Database Client Tools Compatibility
Client Package Description of Contents Client Version Server Versions
Greenplum Clients Greenplum Database Command-Line Interface (psql) 4.3 4.3
Greenplum Connectivity Standard PostgreSQL Database Drivers (ODBC, JDBC1)

PostgreSQL Client C API (libpq)

4.3 4.3
Greenplum Loaders Greenplum Database Parallel Data Loading Tools (gpfdist, gpload) 4.32 4.3
Note:

1The JDBC drivers that are shipped with the Greenplum Connectivity Tools are official PostgreSQL JDBC drivers built by the PostgreSQL JDBC Driver team (https://jdbc.postgresql.org).

2Greenplum Database Loaders 4.3.30.4 are compatible with Greenplum Database servers 4.3.5 and later.

The Greenplum Database Client Tools, Load Tools, and Connectivity Tools are supported on the following platforms:

  • AIX 7.1 and AIX 7.2 (Client and Load Tools only)
  • AIX 5.3L and AIX 6.1 (64-bit)
  • AIX 5.3L (32-bit)
  • Apple OS X on Intel processors (32-bit)
  • HP-UX 11i v3 (B.11.31) Intel Itanium (Client and Load Tools only)
  • Red Hat Enterprise Linux i386 (RHEL 5)
  • Red Hat Enterprise Linux x86_64 6.x (RHEL 6)
  • Red Hat Enterprise Linux x86_64 (RHEL 5)
  • SuSE Linux Enterprise Server x86_64 SLES 11
  • Solaris 10 SPARC32
  • Solaris 10 SPARC64
  • Solaris 10 i386
  • Solaris 10 x86_64
  • Windows 10 (32-bit and 64-bit) (Client and Load Tools only)
  • Windows 8 (32-bit and 64-bit) (Client and Load Tools only)
  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2012 R2 (32-bit and 64-bit) (Client and Load Tools only)
  • Windows Server 2012 (32-bit and 64-bit) (Client and Load Tools only)
  • Windows Server 2003 R2 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit)
  • Windows XP (32-bit and 64-bit)
Important: Support for SuSE Linux Enterprise Server 64-bit 10 SP4 has been dropped for Greenplum Database 4.3.30.4.

Greenplum Command Center

Greenplum Command Center monitors system performance metrics, analyzes system health, and allows administrators to perform some management tasks in a Greenplum environment.

Greenplum Command Center is available from the Pivotal Greenplum page on Pivotal Network.

Table 5. Greenplum Command Center Compatibility
Greenplum Database Version Greenplum Command Center Version
4.3.13.0 and later 3.2.1 and later
4.3.12.0 and earlier All versions except 3.2.1

Greenplum Database Extensions

Greenplum Database delivers an agile, extensible platform for in-database analytics, leveraging the system’s massively parallel architecture. Greenplum Database enables turn-key in-database analytics with Greenplum extensions.

You can download Greenplum extensions packages from Pivotal Network and install them using the Greenplum Packager Manager (gppkg). See the Greenplum Database Utility Guide for details.

Note that Greenplum Package Manager installation files for extension packages may release outside of standard Database release cycles.

The following table provides information about the compatibility of the Greenplum Database Extensions and their components with this Greenplum Database release.

Note: The PL/Python database extension is already included with the standard Greenplum Database distribution.

Pivotal supplies separate PL/Perl extension packages for Red Hat Enterprise Linux 7.x, 6.x and 5.x. Ensure you install the correct package for your operating system.

Table 6. Greenplum Database Extension Components
Greenplum Database Extension Extension Components
Name Version
PostGIS 2.0.2 for Greenplum Database 4.3.x.x PostGIS 2.0.3
Proj 4.8.0
Geos 3.3.8
PL/Java 1.3.2 for Greenplum Database 4.3.x.x PL/Java Based on 1.4.0
Java JDK 1.8.0 Update 172
PL/Java 1.3, 1.3.1 for Greenplum Database 4.3.x.x PL/Java Based on 1.4.0
Java JDK 1.6.0_26 Update 31
PL/R 2.2, 2.3 for Greenplum Database 4.3.x.x PL/R 8.3.0.16
R 3.1.1
PL/R 2.1 for Greenplum Database 4.3.x.x PL/R 8.3.0.15
R 3.1.0
PL/R 1.0 for Greenplum Database 4.3.x.x PL/R 8.3.0.12
R 2.13.0
PL/Perl 1.3 for Greenplum Database 4.3.x.x PL/Perl Based on PostgreSQL 9.1
Perl 5.12.4 on RHEL 7.x, 6.x, 5.x
PL/Perl 1.2 for Greenplum Database 4.3.x.x PL/Perl Based on PostgreSQL 9.1
Perl 5.16.3 on RHEL 7.x

5.12.4 on RHEL 6.x

5.5.8 on RHEL 5.x

PL/Perl 1.1 for Greenplum Database PL/Perl Based on PostgreSQL 9.1
Perl 5.12.4 on RHEL 5.x
PL/Perl 1.0 for Greenplum Database PL/Perl Based on PostgreSQL 9.1
Perl 5.12.4 on RHEL 5.x
Pgcrypto 1.2 for Greenplum Database 4.3.x.x Pgcrypto Based on PostgreSQL 8.3
MADlib 1.x for Greenplum Database 4.3.x.x1 MADlib Based on MADlib version 1.x (1.15.1 - 1.10, 1.9.1, 1.9)
Note: Greenplum Database 4.3.30.4 does not support the PostGIS 1.0 extension package.

1Pivotal recommends that you upgrade to the most recent version of MADlib. For MADlib support and upgrade information, refer to the MADlib FAQ. For information on installing the MADlib extension in Greenplum Database, see Greenplum MADlib Extension for Analytics in the Greenplum Database Reference Guide.

Greenplum Database 4.3.30.4 supports these minimum Greenplum Database extensions package versions.

Table 7. Greenplum Database 4.3.30.4 Package Version
Greenplum Database Extension Minimum Package Version
PostGIS 2.0.2 and release gpdb4.3orca
PL/Java 1.3.2 and release gp4
PL/Perl 1.2 and release gpdb4.3orca
PL/R 2.3 and release gp4
Pgcrypto (see Note) 1.3 and release gpdb4.3orca
MADlib 1.9 and release gpdb4.3orca
Python Data Science Modules 1.0.0 and release gp4
R Data Science Libraries 1.0.0 and release gp4
Note: Extension packages for Greenplum Database 4.3.4.x and earlier are not compatible with Greenplum Database 4.3.5.0 and later due to the introduction of GPORCA. Also, extension packages for Greenplum Database 4.3.5.0 and later are not compatible with Greenplum Database 4.3.4.x and earlier.

To use extension packages with Greenplum Database 4.3.30.4, you must install and use Greenplum Database extension packages (gppkg files and contrib modules) that are built for Greenplum Database 4.3.5.0 or later. For custom modules that were used with Greenplum Database 4.3.4.x and earlier, you must rebuild any modules that were built against the provided C language header files for use with Greenplum Database 4.3.30.4.

For the pgcrypto extension, these restrictions apply.
  • The pgcrypto extension package version pv1.2 and earlier are not compatible with Greenplum Database 4.3.30.4.

    When you upgrade to Greenplum Database 4.3.30.4 and the pgcrypto package version pv1.2 or earlier is installed in your current system, you must uninstall the old pgcrypto extension and install the new pgcrypto extension.

  • The pgcrypto extension package version pv1.3 is not compatible with Greenplum Database 4.3.15.0 and earlier. Do not install this release of the pgcrypto extension in systems running Greenplum Database 4.3.15.0 and earlier.

Package File Naming Convention

For Greenplum Database 4.3, this is the package file naming format.

pkgname-ver_pvpkg-version_gpdbrel-OS-version-arch.gppkg

This example is the package name for a postGIS package.

postgis-ossv2.0.3_pv2.0.1_gpdb4.3-rhel5-x86_64.gppkg

pkgname-ver - The package name and optional version of the software that was used to create the package extension. If the package is based on open source software, the version has format ossvversion. The version is the version of the open source software that the package is based on. For the postGIS package, ossv2.0.3 specifies that the package is based on postGIS version 2.0.3.

pvpkg-version - The package version. The version of the Greenplum Database package. For the postGIS package, pv2.0.1 specifies that the Greenplum Database package version is 2.0.1.

gpdbrel-OS-version-arch - The compatible Greenplum Database release. For the postGIS package, gpdb4.3-rhel5-x86_64 specifies that package is compatible with Greenplum Database 4.3 on Red Hat Enterprise Linux version 5.x, x86 64-bit architecture.

Hadoop Distribution Compatibility

This table lists the supported Hadoop distributions:

Table 8. Supported Hadoop Distributions
Hadoop Distribution Version gp_hadoop_ target_version
Pivotal HD 3 Pivotal HD 3.0, 3.0.1 gphd-3.0
Pivotal HD 2.0, 2.1

Pivotal HD 1.0 1

gphd-2.0
Greenplum HD 3 Greenplum HD 1.2 gphd-1.2
Greenplum HD 1.1 gphd-1.1 (default)
Cloudera CDH 5.2, 5.3, 5.4.x - 5.8.x cdh5
CDH 5.0, 5.1 cdh4.1
Hortonworks Data Platform HDP 2.x hdp2
MapR 2 MapR 4.x, MapR 5.x gpmr-1.2
Apache Hadoop 2.x hadoop2
Notes:
  1. Pivotal HD 1.0 is a distribution of Hadoop 2.0.
  2. MapR requires the MapR client.
  3. Support for these Hadoop distributions has been deprecated and will be removed in a future release: Pivotal HD and Greenplum HD.

Greenplum Database 4.3.30.4 Documentation

For the latest Greenplum Database documentation go to Pivotal Greenplum Database Documentation. Greenplum Database documentation is provided in HTML and PDF formats.

Table 9. Greenplum Database Documentation
Title Revision
Greenplum Database 4.3.30.4 Release Notes A01
Greenplum Database 4.3 Installation Guide A31
Greenplum Database 4.3 Administrator Guide A47
Greenplum Database 4.3 Reference Guide A50
Greenplum Database 4.3 Utility Guide A47
Greenplum Database 4.3 Client Tools for UNIX A09
Greenplum Database 4.3 Client Tools for Windows A07
Greenplum Database 4.3 Connectivity Tools for UNIX A09
Greenplum Database 4.3 Connectivity Tools for Windows A07
Greenplum Database 4.3 Load Tools for UNIX A15
Greenplum Database 4.3 Load Tools for Windows A15
Greenplum Command Center Administrator Guide *

Greenplum Workload Manager User Guide *

----

----

Note: * HTML format only. Documentation is at gpcc.docs.pivotal.io.