Greenplum Database 4.3.x Resolved Issues
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.x Resolved Issues
Consolidated list of resolved issues for the Greenplum Database 4.3.x releases.
|Issue Number||Category||Resolved in||Description|
|24158||Upgrade / Downgrade||220.127.116.11||When upgrading Greenplum Database from a 4.2.x release to a 4.3.x release prior to 18.104.22.168, append-only tables were not correctly converted to append-optimized tables. In some cases, the incorrect conversion prevented the VACUUM command from reclaiming storage occupied by deleted tuples. For information about the upgrade issue, see Product Enhancements.|
|24326||Query Execution, Storage Access Methods||22.214.171.124||If either a non-partitioned append-only
table or an individual append-only part of a partitioned table had more than 127
million rows on a segment, a query that uses an index to access the table data could
return duplicate rows.
This issue has been fixed.
|24037||Client Access Methods and Tools||4.3.2||In some cases, when the SQLCancel function was used with the Greenplum Database ODBC driver to cancel the execution of a query, a rollback of the transaction did not occur.|
|23838||Loaders: Copy/External Tables||4.3.2||When the COPY command copied data from a file and the file contained the character sequence '\r\r\n', a postmaster reset occured.|
|23768||Query Execution||4.3.2||In some cases, the clean up of an aborted transaction was not handled correctly and caused a PANIC signal to be issued.|
|23751||Monitoring: gpperfmon server||4.3.2||A memory leak caused the gpmmon process to consume a large amount of memory and CPU resources.|
|23735||Languages: PL/Java||4.3.2||In some cases, Greenplum Database did not handle concurrent shared memory operations properly from PL/Java routines. This caused a PANIC signal to be issued.|
|23708||Backup and Restore||4.3.2||In some cases, running the Greenplum
Database gpdbrestore utility with the -T or --table-file option failed with this
ValueError: need more than 1 value to unpack
|23706||Upgrade / Downgrade||4.3.2||The Greenplum Database installer did not support upgrading from a Greenplum Database hotfix.|
|23647||Vacuum||4.3.2||Performing a VACUUM operation on a partitioned append-optimized table did not correctly reduce the age of the parent table and child tables.|
|23631||Replication: Segment Mirroring||4.3.2||In some rare cases, the crash recovery of a segment mirror failed due to an inconsistent LSN.|
|23604||Interconnect||4.3.2||In some cases when a Greenplum Database process was cancelled on the Greenplum Database master, corresponding processes remained running on Greenplum Database segment instances.|
|23578||gphdfs||4.3.2||For Greenplum Database external tables, the gphdfs protocol that accesses data from files on HDFS now supports the CSV file format.|
|23546||Storage Access Methods||4.3.2||In some cases, a DELETE command that
contains a join between an append-optimized table and heap table returned this
ERROR: tuple already updated by self
|23485||Transaction Management||4.3.2||When a single Greenplum Database session
ran transactions, temporary files were not removed after the transaction completed.
If a the session ran a large number of transactions, the temporary files required a
large amount of disk space.
This issue has been resolved.
|23417||Transaction Management||4.3.2||Some queries against an append-optimized table with compression enabled that containd a column with an unknown data type caused a Greenplum Database SIGSEGV error.|
|23227||Client Access Methods and Tools||4.3.2||For Greenplum Database with GSS Authentication enabled, the database role attribute Valid Until was ignored. The Valid Until parameter is now respected when GSS authentication is enabled.|
|23222||Client Access Methods and Tools||4.3.2||When Greenplum Database receives a
SIGSEGV when running the COPY command, Greenplum Database hangs and continuously log
this warning message:
copy: unexpected response (3)
|23204||Query Execution||4.3.2||In some cases, when a Greenplum Database segment fault occurred during the execution of a PL/R function, PL/R hung and continuously returned the same error message.|
|23202||Management Scripts: expansion||4.3.2||During the process of adding new hosts, the Greenplum Database expand utility gpexpand did not update the pg_hba.conf files on Greenplum Database hosts with the correct host information.|
|23174||Languages: R, PLR||4.3.2||In Greenplum Database, a signal handling issue in the R programming language caused a potential for postgres processes to hang when running PL/R functions.|
|23138||Replication: Segment Mirroring||4.3.2||The gprecoverseg utility failed to recover a Greenplum Database segment that was marked as down when the data directory location for the segment was a symbolic link, and a postgres process was running with the same PID as the PID associated with the down segment.|
|23067||Loaders: Copy/External Tables||4.3.2||In some cases, when an INSERT FROM SELECT
command was run that selected from readable external able and inserted into writable
external table, this warning was generated:
WARNING select failed on curl_multi_fdset (maxfd 10) (4 - Interrupted system call)
|23038||Query Execution||4.3.2||When a query was run that contained a
polymorphic, user-defined aggregate function, and Greenplum Database was required to
create spill files on disk, the query failed with this error.
ERROR: could not determine actual argument type for polymorphic function
This issue has been fixed.
|23008||Dispatch||4.3.2||In some cases when temporary tables were used, Greenplum Database did not perform the clean up of temporary namespaces properly after a transaction completed and caused a SIGSEGV.|
|22914||Loaders: Copy/ExternalTables||4.3.2||When a query joined a heap table with an external table that used the gpfdist protocol, an incorrect plan that returned no results might have been chosen.|
|22787||Monitoring: gpperfmon server||4.3.2||In some cases, the Greenplum Database gpmmon process failed. The gpmmon process is used for Greenplum Database performance monitoring.|
|22784||Storage Access Methods||4.3.2||After a database expansion, some tables
created with APPENDONLY=TRUE and compression enabled consumed much more disk space
than before the expansion.
To reduce disk space in this situation, the Greenplum Database gpreload utility reloads table data with column data sorted.
|22706||Management Scripts: master mirroring||4.3.2||The Greenplum Database gpinitstandby
utility completed successfully but returned an error when the $GPHOME/share directory was not writable.
Now, the utility returns this warning:
Please run gppkg --clean after successful standby initialization.
|22592||Backup and Restore||4.3.2||When the Greenplum Database gpdbrestore utility could not find files on the Greenplum Database master segment that are used to perform a restore operation, the utility did not return the correct error message.|
|22413||Query Planner||4.3.2||In some cases, an SQL query that contains the following returned incorrect results: a combination of a median function with other aggregates where the GROUP BY columns are a subset of the table's distribution columns.|
|22328||Management Scripts||4.3.2||When a Greenplum Database extension
package was updated with the Greenplum Database gppkg utility option -u, gppkg did
not warn the user that updating a package includes removing all previous versions of
the system objects related to the package.
Now, the gppkg utility warns the user and lets the user cancel the operation.
|22265||Locking, Signals, Processes||4.3.2||Greenplum Database hung due to incorrect lock handling that caused a race condition. The lock handling issue was caused by a compiler optimization.|
|22205||Replication: Segment Mirroring||4.3.2||In some cases, running the Greenplum Database command gprecoverseg -r to rebalance segment instances failed and caused database catalog corruption.|
|21916||Interconnect||4.3.2||In some cases when the Greenplum Database query dispatcher encountered connection errors, a postmaster reset occured.|
|21867||DDL and Utility Statements||4.3.2||The performance of Greenplum Database truncate operations degraded between restarts of Greenplum Database.|
|21103||Query Execution||4.3.2||In Greenplum Database, support of subnormal double-precision (float8) numbers differed between Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6. For example, the value 5e-309 was not handled consistently by Greenplum Database on RHEL 5 and RHEL 6. This issue has been resolved.|
|20600||Query Planner||4.3.2||For some SQL queries that contained a subquery, this error message was returned. ERROR: no parameter found for initplan subquery.|
|20268||Loaders: Copy/ExternalTables||4.3.2||In some cases when a COPY command was run, improper memory handling caused a PANIC signal to be issued.|
|19949||Backup and Restore||4.3.2||If a Greenplum database was backed up and the database name contained upper-case characters, the Greenplum Database gpdbrestore utility did not restore the database with the correct name.|
|19660||Authentication||4.3.2||Greenplum Database supports LDAP authentication. Previously, an issue in Greenplum Database prevented LDAPS (LDAP over SSL) from functioning. This issue has been resolved.|
|19246||Backup and Restore||4.3.2||When performing a selective restore of a
partitioned table from a full backup with the Greenplum Database utility
gpdbrestore, the data from leaf partitions are now restored.
Previously, when performing a selective restore of a partitioned table, you needed to specify all the individual leaf partitions.
|18774||Loaders||4.3.2||External web tables that use IPv6
addresses no longer require a port number when using the default port.
In previous releases, a port number was required when using an IPv6 address.
|13282||Backup and Restore||4.3.2||The database objects in the gp_toolkit schema were not restored after a database was re-created and then restored with the Greenplum Database gpdbrestore utility. The gp_toolkit objects are now restored when a database is re-created and restored.|
|Issue Number||Category||Resolved in||Description|
|23757||Security||4.3.1||Greenplum Database software has been updated to use OpenSSL 0.9.8za in response to the OpenSSL Security Advisory [05 Jun 2014]. For information about the advisory, see http://www.openssl.org/news/secadv_20140605.txt.|
|22301||Replication: Master Mirroring||4.3.1||DCA customers who wished to use Greenplum Database 4.3 could not use the utility dca_setup. This issue has been resolved in Greenplum Database 4.3.1.|
|22281||Backup and Restore||4.3.1||For partitioned append-optimized tables, a partition was backed up even though it was not modified.|
|21591||Management Scripts Suite||4.3.1||The Greenplum Database utilities gpstart and gprecoverseg hung when checking the process ID in the postmaster.pid file and the ID matched a non-postgres running process.|
|23421||Locking, Signals, Processes||4.3.1||In some cases, concurrent CREATE TABLE and DROP TABLE operations caused Greenplum Database to hang due to incorrect lock handling.|
|13825||Functions and Languages, Transaction Management||4.3.1||In PL/PGSQL functions, exception blocks
were not handled properly. Depending on where the exception is encountered during
function execution, the improper block handling resulted in either the creation of
catalog inconsistency between master and segment, or Greenplum Database issuing
the following message:
The distributed transaction 'Prepare' broadcast failed to one or more segments.
|22655||Locking, Signals, Processes||4.3.1||Greenplum Database hung due to incorrect lock handling that caused a race condition. The lock handling issue was caused by a compiler optimization.|
|20924||Dispatch||4.3.1||For some queries that contained a window function and that executed on both the master and segments, the query would hang when executed from an ODBC/JDBC client.|
|21899||Backup and Restore||4.3.1||When performing an incremental backup, the gpcrondump utility backed up temporary tables that existed during the time of the backup. This caused a failure when performing a restore with the gpdbrestore utility that used the incremental backup.|
|22293||Backup and Restore||4.3.1||Greenplum Database supports Data Domain DDOS 5.4. See Supported Platforms for information about supported versions of Data Domain Boost.|
|22442||Loaders: gpfdist||4.3.1||The Greenplum Database Load Tools for Windows installation did not include the gssapi and auth libraries. This issue has been resolved.|
|19476||Client Access Methods and Tools||4.3.1||Running multiple gpload sessions simultaneously that loaded data into the same table resulted in inconsistent data in the table. See the gpload information in Product Enhancements.|
|22863||DDL and Utility Statements||4.3.1||When > (greater than) was used in
the CREATE OPERATOR CLASS command as an operator name, this error
operator > is not a valid ordering operator when using operator classes
|22219||Query Planner||4.3.1||In certain queries that contain the median function and a GROUP BY clause, the query planner produced an incorrect plan in which some necessary columns were not projected in the operator nodes. This caused an error when trying to look up the missing columns.|
|22084||OS Abstraction||4.3.1||Improved handing of situations where Greenplum Database encounters segment violation errors.|
|17995||DDL and Utility Statements||4.3.1||In some cases, the functions pg_cancel_backend() and pg_terminate_backend() did not terminate sessions.|
|17773||DDL and Utility Statements||4.3.1||Greenplum Database did not properly check privileges during certain RESET ALL operations.|
|17481||Catalog and Metadata, DDL and Utility Statements||4.3.1||Queries on the system view pg_partitions could fail to return when DDL statements on partitioned tables were running concurrently.|
|15834||Loaders: Copy/ExternalTabs||4.3.1||A COPY command cancel request (Ctrl+c) followed by another COPY command and a cancel request caused the Greenplum Database session to hang. When cancel request was attempted again, a SIGSEGV error occured.|
|14367||DDL and Utility Statements||4.3.1||ALTER TABLE ADD COLUMN with default NULL was not supported for append-optimized tables. This syntax is now supported.|
|21522||Backup and Restore||4.3||The Greenplum Database utility pg_dump printed information-level messages (messages with the label [INFO]) to stderr that were not printed in previous releases. These messages were printed even when pg_dump completes without errors.|
|21522||Backup and Restore||The Greenplum Database utility pg_dump printed information-level messages (messages with the label [INFO]) to stderr that were not printed in previous releases. These messages were printed even when pg_dump completes without errors.|