Greenplum Database 4.3.16.1 Release Notes

A newer version of this documentation is available. Click here to view the most up-to-date release of the Greenplum 4.x documentation.

Greenplum Database 4.3.16.1 Release Notes

Rev: A03

Updated: August, 2017

Welcome to Pivotal Greenplum Database 4.3.16.1

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.

The pgcrypto extension package version pv1.3 is not compatible with previous Greenplum
Database releases.

Important: Pivotal Support does not provide support for open source
versions of Greenplum Database. Only Pivotal Greenplum Database is supported by Pivotal
Support.

About Greenplum Database 4.3.16.1

Greenplum Database 4.3.16.1 is a patch release that includes product enhancements and
changes, and resolves some known issues. Please refer to the following sections for more
information about this release.

s3 Protocol Support for Proxies

In Greenplum Database 4.3.16.1, the Greenplum Database s3 external table
protocol can be configured to use a URL that is the proxy that S3 uses to connect to a
data source.

The s3 proxy supports these protocols: HTTP, HTTPS, and SOCKS (4, 4a, 5,
5h). You can specify a proxy with the s3 protocol configuration parameter
proxy or environment variables. If the configuration parameter is set,
the environment variables are ignored.

For information about the s3 protocol , see the Greenplum Database
Administrator Guide.

gpinitsytem Options to Customize System Configuration

In Greenplum Database 4.3.16.1, the Greenplum Database utility
gpinitsystem supports the options -O and
-I. With the options, you can customize the configuration of a
Greenplum Database system. The -O option creates a Greenplum Database
system configuration file that contains master, primary, and mirror segment information.
The file is based on the cluster configuration file that you specify with the
-c option and list of host systems. If you specify the
-O option, a new Greenplum Database system is not created.

You can modify the segment instance information in the configuration file before you
create the Greenplum Database system. For example, you can change the mirror instance
configuration on the hosts to spread the load out evenly among the hosts systems.

After modifying the configuration, you create a Greenplum Database system by specifying
the -I option with the modified configuration file.

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

Python Data Science Module Package

Greenplum Database now includes a Python Data Science Module package that you can
optionally install. This package includes a set of commonly-used, open source data science
Python modules. The Python Data Science Module package is available for download in
.gppkg format from Pivotal Network. This
package includes the following Python modules:

R Data Science Library Package

Greenplum Database now includes an R Data Science Library package that you can optionally
install. This package includes a set of commonly-used, open source data science R
libraries. The R Data Science Library package is available for download in
.gppkg format from Pivotal Network.

Refer to the R Data Science Library Package installation guide for additional information
about this package, including the list of libraries provided.

Query Processing Performance Enhancement

Greenplum Database query processing dispatcher has been enhanced to randomly choose a
segment instance as a single reader gang for data consolidation and redistribution.
Choosing a random segment instance helps avoid a performance bottleneck on specific
segments and enhances performance by spreading reader gang work among segments. In
previous releases, a specific segment instance was selected as the single reader gang.

Query Processing Performance Enhancement

Greenplum Database query processing dispatcher has been enhanced to randomly choose a
segment instance as a single reader gang for data consolidation and redistribution.
Choosing a random segment instance helps avoid a performance bottleneck on specific
segments and enhances performance by spreading reader gang work among segments. In
previous releases, a specific segment instance was selected as the single reader gang.

Changed Features

Greenplum Database 4.3.16.1 includes these feature changes:

When running the Greenplum Database gppkg utility with the
--migrate option, at a minimum, the master must be running on the
target Greenplum Database system. The --migrate option migrates
installed Greenplum Database extension packages when you perform a software binary
upgrade. For example, when you perform a patch upgrade.

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

The Greenplum Database PL/Java extension package has been updated for Greenplum
Database 4.3.16.1. The new PL/Java package version is pv1.3.1.This package version
resolves an issue with the JAVA_HOME environment variable that is
incorrectly set in the greenplum_path.sh file. The issue caused a Java
error that stated that libjvm.so did not exist.

For information about
Greenplum extension compatibility, see Greenplum Database Extensions. For
information about the PL/Java extension, see the Greenplum Database Reference
Guide.

Downloading Greenplum Database

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

Greenplum Database 4.3.x software is available from
the Pivotal Greenplum page on Pivotal Network.

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.

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 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.

Greenplum Database 4.3.x, all versions, is supported on DCA V1, and requires DCA
software version 1.2.2.2 or greater due to known DCA software issues in older DCA
software versions.

Note: Greenplum Database 4.3.16.1 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) 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 EBS storage the storage
should be RAID of Amazon EBS volumes and mounted with the XFS file system for it to be a
supported configuration.

Resolved Issues in Greenplum Database 4.3.16.x

The table below lists issues that are now resolved in Pivotal Greenplum Database 4.3.16.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.

This issue has been fixed. The management of
analyzedb snapshot information has been improved.

26910

Query Optimizer

4.3.16.1

In some cases, GPORCA caused a Greenplum Database PANIC when running a query
after cancelling a query that was displaying informational log messages. The
cancelled query caused an inconsistent memory pool state that caused a PANIC when
the subsequent query was run.

This issue has been resolved. GPORCA interrupt
handing has been improved for the specified situation.

26701

gpmigrate

4.3.16.1

When running the Greenplum Database utility gppkg with the
--migrate option, the utility did not correctly migrate the
Greenplum Database extensions installed in an existing installation to an upgrade
installation.

This issue has been resolved. Running gppkg with
the --migrate option migrates installed extensions. Now, at a
minimum, the master must be running on the upgrade Greenplum Database system. See
Changed Features.

149956098

gpload

4.3.16.1

When running the Greenplum Database utility
gpload, the size of log files increased quickly in some
situations. The logs contained information from the gpfdist
instances that were used by gpload. This caused the
gpload logs to increase quickly in some cases.

This issue has
been resolved. The gpload utility no longer includes the
gpfdist information to the log files as the default. The
gpload option -v or -V must
be specified to include gpfdist information.

148821441

PL/Java

4.3.16.1

After installing the PL/Java extension package with the Greenplum Database
utility gppkg, running a Java application returned a Java error
that stated that libjvm.so did not exist. The error was caused by
the JAVA_HOME environment variable that was incorrectly set in the
greenplum_path.sh file.

This issue has been resolved. The
PL/Java extension package has been updated to set JAVA_HOME
correctly. The new PL/Java package version is pv1.3.1. See Changed Features.

28989

Backup and Restore

4.3.16.0

When the Greenplum Database gpdbrestore utility attempted to
restore a schema from a full backup by specifying a schema filtering option
-S, the restore operation failed if a user-defined function
contains a BEGIN ... END block and the function is not qualified by
the schema. The utility would incorrectly run the BEGIN ... END
block.

This issue has been resolved. Now the utility correctly handles
user-defined functions in the specified situation.

28972

Query Optimizer

4.3.16.0

GPORCA generated a Greenplum Database PANIC when a query contains a function
where an input argument is a subquery. GPORCA did not handle the subquery correctly
and generated a PANIC.

This issue has been resolved. Now GPORCA correctly
processes subqueries when they are input arguments to a function in a
query.

28968

Backup and Restore

4.3.16.0

When running the Greenplum Database gpdbrestore utility with
the -S option to restore database objects qualified by a specified
schema from a backup, the utility was not restoring access privilege information
(GRANT privileges) for the schema.

This issue has been
resolved. When restoring database objects with the -S option, the
access privilege information for the schema is restored.

28967

Backup and Restore

4.3.16.0

When restoring a database with the gpdbrestore utility, the
access privilege information (GRANT privileges) that was set for
the database was missing. The missing access privilege information was not being
backed up by the Greenplum Database gpcrondump utility.

This
issue has been resolved. Now, the gpcrondump utility backs up the
database level access privilege information and is restored by the
gpdbrestore utility.

28963

Query Executor

4.3.16.0

In some cases, when Greeplum Database executes a query with a
JOIN, when the hash side of the hash join operator is empty, an
optimization in the executor skips executing the probe side of the join operator
("squelching"). Previously the executor was too aggressive in squelching. If the
probe side of the hash join has SharedInputScans, there could be circumstances where
a SharedInputScan reader could hang if the SharedInputScan writer was squelched.

This issue has now been resolved in the Greeplum Database executor.

27007

26964

Query Planner

4.3.16.0

For queries that contained distinct qualified aggregates (DQA) and grouping
sets (GROUPINGSET, ROLLUP, CUBE), the Greenplum
Database legacy optimizer incorrectly replaced the grouping columns appearing in the
projection list while producing a plan with an Append node. This caused a Greenplum
Database PANIC.

This issue has been resolved. Now the legacy optimizer generates
a correct plan for the specified queries.

27000

Transaction Management

4.3.16.0

In some cases, Greenplum Database issued an error indicating a missing chunk
number for a toast value. The error could have occurred when a mirror segment took
over as a primary segment or when a rebalance occurred. The error was caused by to
the improper handling of blocks of data during incremental recovery with the
Greenplum Database gprecoverseg utility. The improper data handling
caused the mirror segment to be incorrectly marked as in-sync with primary
segment.

This issue has been resolved. The handling of blocks during incremental
recovery has been improved.

26908

GPHDFS

4.3.16.0

Greenplum Database performance was poor for queries with a
LIMIT clause that accessed an external table with the
gphdfs protocol. The poor performance was caused by Greenplum
Database not efficiently managing the freeing of resources after the query
completes.

This issue has been resolved. Greenplum Database has improved how
resources are freed for queries against external tables.

26865

gpfdist

4.3.16.0

When an HTTP request with a malformed or root (/) URL was sent
to the Greenplum Database utility gpfidst, the utility resets and
generates an error that extra data was detected .

This issue has been resolved.
The utility has been enhanced and now detects issues with a HTTP request and
returns an error message indicating the error.

26663

Locking, Signals, Processes

4.3.16.0

In some cases on a Greenplum Database system, a running query could not be
canceled with the pg_cancel_backend() command. The query could not
be cancelled because during query processing, a backend query process was placed in
a state that did not check for an interrupt such as a
pg_cancel_backend() command.

This issue has been resolved.
Checking for interrupts by backend query processes have been improved.

26441

gpfdist

4.3.16.0

For a Greenplum Database writable external table defined with the
gpfdists protocol (gpfdist with SSL) was much
slower that a table defined with the gpfdist protocol.

This issue
has been resolved. The gpfdists protocol performance has been
improved by upgrading the OpenSSL version used by Greenplum Database.

148133765

PL/R

4.3.16.0

After installing the Greenplum Database PL/R extension package version pv2.2 on
a CentOS 7.x or RHEL 7.x system, running the rpm utility failed.
with the message version `XZ_5.1.2alpha' not found (required by
/lib64/librpmio.so.3) This issue also affects the Greenplum Database
gppkg utility that uses rpm.

This issue has
been resolved. Installing the PL/R extension package version pv2.3 does not cause
the rpm failure.

Known Issues in Greenplum Database 4.3.16.x

This section lists the known issues in Greenplum Database 4.3.16.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 4. All Known Issues in 4.3.16.x

Issue

Category

Description

26675

gpcrondump

During the transition from Daylight Saving Time to Standard Time, there is a
particular 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:
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.

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.

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.

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.

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.16.x

The upgrade path supported for this release is Greenplum Database 4.2.x.x to Greenplum
Database 4.3.16.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.

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.16.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, upgrade to MADlib 1.10 or 1.11 on Greenplum Database 4.3.16.x. If you do not upgrade to MADlib 1.10 or later, the
MADlib madpack utility will not function. The MADlib analytics
functionality will continue to work. If you upgrade to MADlib 1.9.1, 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.

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.16.x

An upgrade from 4.3.x to 4.3.16.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.

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

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

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.

Log in to your Greenplum Database master host as the
Greenplum administrative user:

$ su - gpadmin

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.

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

Run the installer for 4.3.16.x on the Greenplum Database master host.

When prompted, choose an
installation location in the same base directory as your current installation. For
example:

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.16.1/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:

Run the gpseginstall utility to install the 4.3.16.x
binaries on all the segment hosts specified in the hostfile. For
example:

$ gpseginstall -f hostfile

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.

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.

After all segment hosts have been upgraded, you can
log in as the gpadmin user and restart your Greenplum Database
system:

# su - gpadmin
$ gpstart

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.

Run the fix_ao_upgrade.py utility with the option
--report. The following is an
example.

(optional) Run the fix_ao_upgrade.py utility with the
option --report again. No inconsistencies should be reported.

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.

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

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.16.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.

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.16.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.16.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.

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.16.x on
Pivotal DCA Systems

Upgrading Greenplum Database from 4.3.x to 4.3.16.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.16.x on DCA systems. This section is only for
installing Greenplum Database 4.3.16.x on DCA systems.

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

Download or copy the installer file to the Greenplum Database
master host.

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.

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

As root, run the Pivotal DCA installer for 4.3.16.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.

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.

After all segment hosts have been upgraded, you can log in as the
gpadmin user and restart your Greenplum Database
system:

# su - gpadmin
$ gpstart

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.

Run the fix_ao_upgrade.py utility with the option
--report. The following is an
example.

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.16.x

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

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.

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).

Log in to the Greenplum Database master as the
gpadmin
user:

# su - gpadmin

(optional)
Vacuum all databases prior to upgrade. For
example:

$ vacuumdb database_name

(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.

Run gpstate to check for
failed segments.

$ gpstate

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.

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.

Download or copy the installer file to the
Greenplum Database master host.

Unzip the installer file. For
example:

# unzip greenplum-db-4.3.16.1-PLATFORM.zip

Launch the installer using bash. For
example:

# /bin/bash greenplum-db-4.3.16.1-PLATFORM.bin

The installer will prompt you to accept the
Greenplum Database license agreement. Type yes to accept the license agreement.

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.16.1), or enter an absolute path to
an install location. You must have write permissions to the location you specify.

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.

Source the path file from your new 4.3.16.x installation. This example changes to the
gpadmin user before sourcing the
file:

Run the gpseginstall utility to install the 4.3.16.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.

Download or copy the installer file to the Greenplum Database
master host.

As root, run the Pivotal DCA installer for 4.3.16.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.16.1.

# ./greenplum-db-appliance-4.3.16.1-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.

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.

(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.

If your system has a standby master host
configured, remove the standby master from your system configuration. For
example:

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.16.1 /usr/local/greenplum-db

(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:

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.16.1.

As gpadmin, run the 4.3.16.1
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:

The migration can take a while to complete.
After the migration utility has completed successfully, the Greenplum Database 4.3.16.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.16.x system)

If your system had a standby master host
configured, reinitialize your standby master using gpinitstandby:

$ gpinitstandby -s standby_hostname

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.

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.

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.

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.

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.

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 5. 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).

Note: Greenplum Database 4.3.16.1 does not support the PostGIS 1.0 extension
package.

Pivotal recommends that you upgrade to MADlib 1.10 or 1.11 on Greenplum
Database 4.3.10.0 and later releases. If you do not upgrade MADlib, the MADlib
madpack utility will not function on Greenplum Database. The MADlib
analytics functionality will continue to work. See "Greenplum MADlib Extension for
Analytics", in the Greenplum Database Reference Guide.

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.16.1, 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.16.1.

For the pgcrypto extension, these restrictions apply.

The pgcrypto extension package version pv1.2 and earlier are not compatible with
Greenplum Database 4.3.16.1.

When you upgrade to Greenplum Database 4.3.16.1 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.