Greenplum Database 6.4.0 includes these changed features:

• DISCARD ALL is not supported. The command returns a message that states that the command is not supported and to consider alternatives such as DEALLOCATE ALL or DISCARD TEMP. See DISCARD.
• Greenplum Database resource groups support automatic query termination when resource group global shared memory is enabled. For resource groups that use global shared memory, Greenplum Database gracefully cancels running queries that are managed by those resource groups when the queries consume a large portion of the global shared memory. At this point, the queries would have already consumed available resource group slot memory and group shared memory. Greenplum Database cancels queries in order of memory used, from highest to lowest until the percentage of utilized global shared memory is below the percentage specified by the server configuration parameter runaway_detector_activation_percent.

  Global shared memory is enabled for resource groups that are configured to use the vmtracker memory auditor, such as admin_group and default_group when the sum of the MEMORY_LIMIT attribute values configured for all resource groups is less than 100. If resource groups are not configured to use global shared memory pool, the resource group automatic query termination feature is not enabled.

  For information about resource groups, see Using Resource Groups.

• Greenplum Database supports creating the standby master or mirror segment instances on hosts that are in a different subnet from the master and primary segment instance hosts. Mirror segment instances can also be moved to hosts that are in a different subnet.

Pivotal Greenplum 6.4.0 resolves these issues:

30209, 170762049 - gpaddmirrors

The gpaddmirrors utility failed to add mirror segments to a Greenplum Database system, when the mirror segments are in a different subnet from the primary segments. This issue is resolved. Now Greenplum Database supports mirror segments in a different subnet from the primary segments.

30266 - Vacuum

The vacuum workflow changed in Greenplum Database 6 to dispatch once per auxiliary table in addition to the dispatch for the main table. This could cause performance problems and permission verification failures on auxiliary tables. This is fixed. The VACUUM command again dispatches once per segment.

30282 - Resource Management

For some queries managed by Greenplum Database resource groups, the query failed due to an out of memory condition. This caused a segment failure and other issues. This issue is resolved. Resource groups have been enhanced to handle queries that consume a large amount of memory. See Changed Features.

30299 - Server: Execution

For some queries against a partitioned table with multiple column indexes that perform a dynamic index scan, Greenplum Database generated a SIGSEGV. The error occurred when Greenplum Database did not correctly manage dynamic index scan pointer memory. This issue is resolved.

30325 - Query Optimizer

For some queries that reference a view that is defined with a CTE (common table expression) query, and the main query also contains a predicate that is a subquery that references the view, GPORCA returns an error that states could not open temporary file. The error was caused by incorrect predicate pushdown during preprocessing. This issue is resolved.

30359 - Server: Segment Mirroring

A panic occurred during crash recovery for a mirror when replaying WAL records for a transaction that created an append-optimized table, truncated the table, and then aborted the transaction. This issue is resolved.

30354 - DISCARD

DISCARD TEMP might not drop temporary tables on segment instances. This issue is resolved.

30360 - Server: Security

Greenplum Database incorrectly logged the message time constraints added on superuser role every time a superuser role was checked. Now the message is logged only when time constraints are added to a superuser role.

30366 - Server: Execution

Using GRANT commands on partitioned tables across segments would cause the system to PANIC due to alterations in the cached plan. This issue has been resolved.

30371 - Server: Execution

The to_timestamp() function did not return an error for an out of range value. For example, select to_timestamp('20200340123456','YYYYMMDDHH24MISS'); returned a valid date and time 2020-04-09 12:34:56-07. This issue is resolved. Now the function returns an error.

30387 - Server: DML

After completing the execution of a user-defined function that changed the value of a server configuration parameter, Greenplum Database restored the original parameter value on the query dispatcher, but did not synchronize and restore the value to the query executors. This issue is resolved.

170787232 - Server: Query Dispatcher

A Query Dispatcher (QD) would run into local deadlock for some prepared statements that execute an UPDATE or DELETE command. This issue has been fixed by taking into consideration the server configuration parameter gp_enable_global_deadlock_detector.

See Upgrading from an Earlier Greenplum 6 Release to upgrade your existing Greenplum 6.x software to Greenplum 6.4.0.