WIXLIB

Greenplum Database 4.3.17.1 Release NotesRelease NotesSupported Platform NotesImportant: When data loss is not acceptable for a Pivotal Greenplum Database cluster, masterand segment mirroring must be enabled in order for the cluster to be supported by Pivotal. Withoutmirroring, system and data availability is not guaranteed, Pivotal will make best efforts to restore acluster in this case. For information about master and segment mirroring, see About Redundancyand Failover in the Greenplum Database Administrator Guide.The following notes describe platform support for Greenplum Database. Please send any questions orcomments to Pivotal Support at https://support.pivotal.io. The only file system supported for running Greenplum Database is the XFS file system. All other filesystems are explicitly not supported by Pivotal.Greenplum Database is supported on all 1U and 2U commodity servers with local storage. Specialpurpose hardware that is not commodity may be supported at the full discretion of Pivotal ProductManagement 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 presentedas a block device to the servers running Greenplum Database and the XFS file system is mountedon the block device. Network file systems are not supported. When using network or sharedstorage, Greenplum Database mirroring must be used in the same way as with local storage, and nomodifications may be made to the mirroring scheme or the recovery scheme of the segments. Otherfeatures of the shared storage such as de-duplication and/or replication are not directly supported byPivotal Greenplum Database, but may be used with support of the storage vendor as long as they donot 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 storageis presented as block devices and the XFS file system is mounted for the storage of the segmentdirectories.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 Amazoninstance 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 EBSvolumes and mounted with the XFS file system for it to be a supported configuration.For Red Hat Enterprise Linux 7.2 or CentOS 7.2, the default systemd setting RemoveIPC yesremoves IPC connections when non-system users logout. This causes the Greenplum Databaseutility gpinitsystem to fail with semaphore errors. To avoid this issue, see "Setting the GreenplumRecommended OS Parameters" in the Greenplum Database Installation Guide.Resolved Issues in Greenplum Database 4.3.17.xThe table below lists issues that are now resolved in Pivotal Greenplum Database 4.3.17.xFor issues resolved in prior 4.3 releases, refer to the corresponding release notes. Release notes areavailable from the Pivotal Greenplum page on Pivotal Network or on the Pivotal Greenplum Databasedocumentation site at Release Notes. A consolidated list of resolved issues for all 4.3 releases is alsoavailable on the documentation site.6

Greenplum Database 4.3.17.1 Release NotesRelease NotesTable 2: Resolved Issues in 4.3.17.xIssueNumberCategoryResolved InDescription29069QueryOptimizer4.3.17.1GPORCA query optimization performance was poor forqueries that contain an IN operator with a large number ofvalues and the values require an implicit CAST.This issue has been resolved. Query optimizationperformance has been improved for the specified type ofqueries.29060QueryPlanner4.3.17.1When an UPDATE or DELETE command on a partitionedtable contains a filter on partitioning key, the GreenplumDatabase legacy query optimizer produced a suboptimalplan. The plan contained a dummy join node with a OneTime False filter for each eliminated partition.This issue has been resolved. Now the legacy optimizerdoes not create such dummy join nodes.29042QueryPlanner4.3.17.1The legacy query optimizer generated a GreenplumDatabase PANIC when executing some aggregationqueries. The queries contain column aliases with the samename as the table columns, the queries contain subqueriesthat reference the column alias, and grouping is appliedon the column alias. In some cases, the legacy optimizercaused a PANIC when it attempted to generate a plan thatcontained a inconsistent target list for the aggregation plan.This issue has been resolved. The legacy optimizergenerates the correct query plan for the specified type ofaggregation queries.29039QueryOptimizer4.3.17.1GPORCA generated a PANIC when a query attempted touse an index on a table column after the table was alteredby dropping columns that are listed earlier in the tabledefinition. For example, the index is defined on column10, and columns 3 and 4 were deleted from the table.GPORCA did not correctly determine the index associatedwith the column.This issue has been resolved. Now GPORCA correctlydetermines the column index in the specified situation.29024QueryPlanner4.3.17.1For some queries that contain a subquery, and thesubquery contains a parameter referencing the outerquery, the Greenplum legacy query optimizer generated anincorrect plan that did not handle the subplan correctly. AGreenplum Database PANIC occurred during query planexecution.This issue has been resolved. The handling of subqueriesby the legacy optimizer has been improved.7

Greenplum Database 4.3.17.1 Release NotesRelease NotesIssueNumberCategoryResolved InDescription29005QueryPlanner4.3.17.1For some DELETE or UPDATE commands that containsubqueries that reference the same table, the GreenplumDatabase legacy query optimizer generated a plan thatdid not correctly redistribute some rows to the appropriatesegments. This caused a Greenplum Database PANICwhen attempting to update or delete a row on an incorrectsegment.This issue has been resolved. Now the plan generatedby the legacy optimizer correctly redistributes rows in thespecified situation.26993gptransfer4.3.17.1The Greenplum Database utility gptransfer failedintermittently when transferring large amounts of data.When exporting data, Greenplum Database did notproperly check whether a write operation had completed.This might cause intermittent failures when exporting largeamounts of data in a single operation.This issue has been resolved. Checking the completion ofwrite operations during data export has been improved.151498144gpcrondump4.3.17.1When backing up and restoring database objects withthe Greenplum Database utilities gpcrondump andgpdbrestore and specifying a schema level option suchas the gpcrondump option -s or -S, functions (which areschema specific) were backed up and restored. However,only the PL/Java language was backed up and restored.This issue has been resolved. Now for schema level backup and restore operations, procedural languages areincluded. See Changed Feature.151344210QueryPlanner4.3.17.1For an aggregation query, the Greenplum Database legacyquery optimizer might return incorrect results when theaggregation is over a column, a CAST is defined on thecolumn, and the original column (without the CAST) is in aGROUP BY clause. The legacy optimizer did not handle theCAST correctly in the query.This issue has been resolved. Now the legacy optimizerhandles the CAST correctly for the specified queries.151341000Backup andRestore4.3.17.1In some cases for a Greenplum Database system with10 or more segment instances, the Greenplum Databasegpdbrestore utility did not perform a restore operationcorrectly. When restoring from a version 4.3.11.3 or earlierbackup to version 4.3.12.0 or later, the utility did not handlethe backup filenames correctly. The format of backupfilenames changed in 4.3.12.0.This issue has been resolved. Now the utility, handles thebackup filenames correctly in the specified situation.8

Greenplum Database 4.3.17.1 Release NotesRelease NotesIssueNumberCategoryResolved InDescription151016845QueryOptimizer4.3.17.1For queries involving catalog tables, GPORCA falls back toGreenplum Database legacy optimizer. The fallback eventwas set to the log severity level LOG and was capturedin the Greenplum Database logs. In some cases, themessages bloated the Greenplum Database log files. Forexample, when a workload executed a large number ofqueries against catalog tables.The issue has been resolved. Now the log level for thefallback event is DEBUG1. This level does not log thefallback events by default. The log level can be set to logthe events for debugging purposes.150988530QueryOptimizer4.3.17.1In some cases, GPORCA generated incorrect results for aquery when the query predicate contains a [NOT] EXISTSclause that contains both an aggregate function and aGROUP BY clause where a grouping column is a outerreference that is not in the aggregate function. GPORCAdid not process the predicate correctly.This issue has now been resolved. Now GPORCA handlesthe specified type of predicate correctly.150906152QueryOptimizer4.3.17.1For some queries that contain a correlated subqueryand the subquery contains a window function, GPORCAgenerated a query plan that returned incorrect results.The plan incorrectly performed the join after the windowfunction was applied.This issue has been resolved. Now the plan generated byGPORCA correctly applies the window function before thejoin.29039QueryOptimizer4.3.17.0GPORCA generated a PANIC when a query attempted touse an index on a table column after the table was alteredby dropping columns that are listed earlier in the tabledefinition. For example, the index is defined on column10, and columns 3 and 4 were deleted from the table.GPORCA did not correctly determine the index associatedwith the column.This issue has been resolved. Now GPORCA correctlydetermines the column index in the specified situation.29036COPY4.3.17.0In some cases, a COPY command caused the GreenplumDatabase to go into recovery mode. This issue was causedby the format of metadata associated with data copied intothe database.This issue has been resolved. In the command, thechecking of metadata has been enhanced.9

Greenplum Database 4.3.17.1 Release NotesRelease NotesIssueNumberCategoryResolved InDescription29030QueryOptimizer4.3.17.0For queries that contain a large number of joins, GPORCAspent a significant amount of time evaluating all possiblemultiple join combinations to determine the most efficientjoin tree to use in the query plan.This issue has been resolved. The maximum number ofjoin combinations that are evaluated has been reduced.29027Backup andRestore4.3.17.0When performing a restore operation that specified aschema filtering option -S, the Greenplum Database utilitygpdbrestore analyzed tables in all the schemas.This issue has been resolved. Now the utility analyzes onlythe tables in the restored schemas.29025Backup andRestore4.3.17.0Some restore operations performed by the GreenplumDatabase utility gpdbrestore that used DD Boost failedbecause of issues parsing DD Boost path information in thebackup report file.This issue has been resolved. Now the utility correctlyparses DD Boost path information.29005QueryPlanner4.3.17.0For some DELETE or UPDATE commands that containsubqueries that reference the same table, the GreenplumDatabase legacy query planner generated a plan that didnot correctly redistribute some rows to the appropriatesegments. This caused a Greenplum Database PANICwhen attempting to update or delete a row on an incorrectsegment.This issue has been resolved. Now the plan generatedby the legacy planner correctly redistributes rows in thespecified situation.28949QueryPlanner4.3.17.0For some DELETE or UPDATE commands that containsubqueries that reference the same table, the GreenplumDatabase legacy query planner generated a plan thatcaused a Greenplum Database PANIC. The plan did notaccount for some columns projected by the join.This issue has been resolved. Now the plan generated bythe legacy planner accounts for all columns in the specifiedsituation.27011gpload4.3.17.0On AIX 7.1 systems, the Greenplum Database client loaderutility gpload failed with a Python not found message.This issue has been resolved. The Greenplum DatabaseClient Loader tools have been updated.10

Greenplum Database 4.3.17.1 Release NotesIssueNumberCategoryResolved In26834Transaction4.3.17.0ManagementRelease NotesDescriptionA DDL or VACUUM operation that creates or drops anappend-optimized segment file requires a shared buffer. Insome cases, this operation caused a deadlock with otheroperations that require the shared buffer.This issue has been resolved. To avoid a deadlock in thespecified situation, the handling of locks for the sharedbuffer has been improved.26832gpcheckcat4.3.17.0When the Greenplum Database utility gpcheckcatchecked multiple databases in a single operation, the utilityincorrectly reported catalog issues for a database when theissue was found in a database that was checked earlier.This issue has been resolved. Now when checking multipledatabases, the utility reports the catalog issues correctly foreach database.26825QueryPlanner4.3.17.0For queries that contain an IN clause that includes acorrelated subquery with a LIMIT or OFFSET clause, thelegacy query planner did not properly handle the LIMIT orOFFSET clause. This issue generated a SIGSEGV.This issue has been resolved. Now the query plannerhandles the specified type of queries correctly.26778gpinitsystem4.3.17.0The Greenplum Database utility gpinitsystem didnot initialize a Greenplum Database system correctlywhen the initialization of the standby master failed. Thestandby master failure caused errors creating gp toolkitadministrative schema and setting server configurationparameters. The failure and errors were not handledcorrectly.These issues have been resolved. Now the failure of thestandby master initialization, does cause the gp toolkitand parameter issues. Also, error handling and logging ofthe specified errors have been improved.26598gpload4.3.17.0The Greenplum Database utility gpload wouldintermittently hang. The issue was caused by gpfdistinstances that were used by gpload. A function used bygpfdist was not re-entrant.This issue has been resolved. Now the function is reentrant.26363GPHDFS4.3.17.0Performance was poor when reading data from Parquetfiles with a Greenplum Database external table defined withthe gphdfs protocol.This issue has been resolved. Performance has beenimproved when reading Parquet data with the gphdfsprotocol.11

Greenplum Database 4.3.17.1 Release NotesRelease NotesIssueNumberCategoryResolved InDescription15254gpconfig4.3.17.0The Greenplum Database utility gpconfig did notproperly set the server configuration parameter pljavaclasspath. After setting the parameter, restartingGreenplum Database with the gpstop -arcommandwould fail. Specifying the value for the parameter in thecommand required enclosing the value in single quotes andthen in double quotes.This issue has been resolved. The use of quotes whenspecifying parameter values has been simplified.151028970QueryOptimizer4.3.17.0For queries that contain a FULL OUTER JOIN with joincondition ON FALSE, GPORCA generated an incorrectplan that returned wrong results. GPORCA incorrectlyreturned an empty set for the full outer join that caused thequery plan to return no tuples.This issue has now been resolved. Now GPORCAgenerates a correct plan.149524459QueryOptimizer4.3.17.0When GPORCA attempted to CAST an integer array to adouble precision array, GPORCA did not perform the CASTof the array elements correctly.This issue has been resolved. GPORCA now performs theCAST correctly.Known Issues in Greenplum Database 4.3.17.xThis section lists the known issues in Greenplum Database 4.3.17.x. A workaround is provided whereapplicable.For known issues discovered in previous 4.3.x releases, see the release notes available from the PivotalGreenplum page on Pivotal Network or on the Pivotal Greenplum Database documentation site at ReleaseNotes. For known issues discovered in other previous releases, including patch releases to GreenplumDatabase 4.2.x, 4.1 or 4.0.x, see the corresponding release notes, available from Dell EMC Support ZoneTable 3: All Known Issues in 4.3.17.xIssueCategoryDescription151135629COPYWhen the ON SEGMENT clause is specified, the COPY commanddoes not support specifying a SELECT statement in the COPY TOcommand. However, this command completes successfully, but thefiles are not created on the segment hosts.COPY (SELECT * FROM testtbl)TO '/tmp/mytst SEGID ' ON SEGMENT12

Greenplum Database 4.3.17.1 Release NotesRelease ementWhen the server configuration parameter gp strict xml parseis set for a session and the session is idle for longer than gp vmemidle resource timeout, the value of gp strict xml parsechanges back to the value set for the system (or the database if theparameter is set for the database).29064Storage: DDLThe 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 (32bit for Greenplum Database 4.x, or 64-bit for Greenplum Database 5.x). Or, use an alternative datatype such as numeric or decimal.28947AccessMethodsA deadlock might occur on an append-optimized columnar tablewhen a VACUUM operation and an INSERT operation are performedconcurrently on the table.WORKAROUND: If a deadlock condition occurs, terminate theINSERT operation to break the deadlock. To eliminate the possibilityof encountering this issue, avoid concurrent VACUUM and INSERToperations.26675gpcrondumpDuring the transition from Daylight Saving Time to Standard Time,this sequence of events which might cause a gpcrondump backupoperation to fail.If an initial backup is taken between 1:00AM and 2:00AM DaylightSaving Time, and a second backup is taken between 1:00AM and2:00AM Standard Time, the second backup might fail if the firstbackup has a timestamp newer than the second.Pivotal recommends performing only a single backup between thehours of 1:00AM and 2:00AM on the days when the time changes: November 5, 2017November 4, 2018November 3, 2019If the failure scenario is encountered, it can be remedied by restartingthe backup operation after 2:00AM Standard Time.146542311gploadWhen running the Greenplum Database utility gpload on AIXsystems, the utility returns an error if the YAML control file forutility contains a line that specifies the \ (backslash) as the escapecharacter, ESCAPE: '\'. The error states that the \ at the end of astring could not be decoded.Workaround: To avoid the error, remove the line from the file, orspecify the line without a character, ESCAPE:. The \ character is thedefault escape character. The line is not required in the file.13

Greenplum Database 4.3.17.1 Release NotesRelease NotesIssueCategoryDescription142743943S3 ExternalTablesThe s3 protocol might not handle the header row in data filesproperly in this situation: A readable external table is defined with the s3 protocol and theHEADER option.The external table has been exchanged to be a leaf child table ofa partitioned table.Queries against the partitioned table might return an error.26591QueryExecutionFor the Greenplum Database function get ao compressionratio(), specifying a null value or the name of table that containsno rows causes a Greenplum Database PANIC.Workaround: Specify a non-null value or a table that contains rows.115746399OperatingSystemFor Greenplum Database that is installed on Red Hat EnterpriseLinux 7.x or CentOS 7.x prior to 7.3, an operating system issue mightcause Greenplum Database that is running large workloads to hangin the workload. The Greenplum Database issue is caused by Linuxkernel bugs.Workaround: RHEL 7.3 and CentOS 7.3 resolves the issue.26626GPHDFSFor Greenplum Database external tables, the gphdfs protocolsupports Avro files that contain a single top-level sch

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