Tanzu Greenplum 5.29.x Release Notes

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

This document contains pertinent release information about Tanzu Greenplum Database 5.29.6. For previous versions of the release notes for Greenplum Database, go to Greenplum Database Documentation. For information about Greenplum Database end of life, see the Support Lifecycle Policy.

Tanzu Greenplum 5.x software is available for download from the Tanzu Greenplum page on Tanzu Network.

Tanzu Greenplum 5.x is based on the open source Greenplum Database project code.

Important: The Greenplum gpbackup and gprestore utilities are now distributed separately from Greenplum Database, and are updated independently of the core Greenplum Database server. These utilities will not be updated in future Greenplum Database 5.x releases. You can upgrade to the latest gpbackup and gprestore versions by downloading and installing the latest Greenplum Backup and Restore release from VMware Tanzu Network.

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

Release 5.29.10

Release Date: 2022-10-28

Resolved Issues

The listed issues are resolved in Greenplum Database 5.29.10.

11948 - Server

Resolved a crash that could occur because Greenplum incorrectly allowed REINDEX TABLE on a partitioned table from within a PL/SQL function. Because REINDEX TABLE on partitioned table expands the table and starts a new transaction to reindex each table, the operation cannot be rolled back and may crash if called within PL/SQL. The code was modified to prevent this operation from running inside of a function.

12989 - Server

Resolved a problem where repeated errors could be reported during certain queries involving pg_locks and a partitioned table.

14137 - Release Engineering

Merged several Python dependencies into the main Greenplum Database repository to simplify the build process.

32524 - Server

Resolved a problem where queries could not be canceled using pg_cancel_backend() or pg_terminate_backend(), because the server would lock up after a connection loss.

32428 - Data Flow

Resolved a problem that prevented certain SSL algorithms, such as ECDHE-RSA-AES256-GCM-SHA384, from being applied during SSL handshake in libpq.

32408 - Server

Resolved a segmentation fault that could occur during a server restart after gp_before_filespace_setup was enabled.

Release 5.29.8

Resolved Issues

The listed issues are resolved in Greenplum Database 5.29.8.

32397 - Server

Resolved a segfault that could occur in cases where the master segment dispatched internal parameters that contained non-initialized values. The problem was fixed by intercepting such parameters at the Query Executor before deserialization occurs.

32381 - Server

Greenplum 5.29.8 resolves Postgres CVE-2022-2625: Extension scripts replace objects not belonging to the extension.

Release 5.29.7

Resolved Issues

The listed issues are resolved in Greenplum Database 5.29.7.

32191 - Server

By default VACUUM FULL cannot vacuum tuples in utility mode, because all tuples are considered to be “live” while in utility mode. Workaround: In cases where it is required to vacuum tuples in utility mode, set the configuration parameter gp_disable_dtx_visibility_check to true. This setting makes all tuples eligible for VACUUM in utility mode.

32179, 31372, 9864 - Data Flow

Resolved a gpfdist problem that could cause errors similar unknown meta type 1xx (url_curl.c:xxxx) when loading data after upgrades to Tanzu Greenplum 6.

Release 5.29.6

Changed Features

Greenplum Database 5.29.6 includes these changes:

Resolved Issues

The listed issues are resolved in Greenplum Database 5.29.6.

For issues resolved in prior 5.x releases, refer to the corresponding release notes. Release notes are available from the Greenplum page on VMware Tanzu Network.

181673873 - Query Processing

The gp_toolkit function was yielding unexpected results because ORCA was relying on fallback plans to hide differences between ORCA and PLANNER; because the differences were hidden, exceptions weren’t being caught. This issue has been resolved.

181229489 - gpload

Resolves an issue where gpload wasn’t respecting case-sensitivity enforcement through the use of double quotes for its staging table name and column names.

11215 - Server

Resolved a problem where partition elimination did not work inside a PL/pgSQL function. The problem occurred because PL/pgSQL used only the plan cached by the Postgres Planner to reevaluate prepared queries, instead of also considering query parameters. The problem was resolved for the Postgres Planner by ensuring that PL/pgSQL considers both the cached plan and parameters when reevaluating a plan.

32075 - Server

Resolved an issue where a duplicated call in pgstat_read_statsfile() would hit the file allocation limit and result in an error similar to too many private files demanded. The issue has been resolved by removing the duplicate call.

32132 - Server

Resolved a problem where certain Greenplum Command Center metrics queries failed to consider the possibility of a NULL value for a database name, which could result in a PANIC and segment failure. The problem was resolved by adding a check to account for NULL database name values.

Release 5.29.5

Resolved Issues

The listed issues are resolved in Greenplum Database 5.29.5.

For issues resolved in prior 5.x releases, refer to the corresponding release notes. Release notes are available from the Greenplum page on VMware Tanzu Network.

32102, 8012 - gpfdist

Resolved an issue where gpfdist would fail to load some data in a .gz data file if the file contained multiple end-of-file (EOF) flags. gpfdist code was modified so that it continues reading from a .gz data file until it reaches the actual EOF flag.

32080 - gpload

Resolves an issue where gpload, when REUSE_TABLES: true, could not find a staging table to reuse, and failed to create the staging table in the public schema. This issue is resolved; gpload now creates staging tables in the same schema as specified by EXTERNAL: SCHEMA:.

32064 - Query Processing

For queries defined inside a user-defined function (UDF), GPORCA tries to evaluate the predicate for static partition elimination on the partitioned table when it executes the parent query. This requires GPORCA to plan, optimize, and execute statements inside the UDF. However, GPORCA does not support nested optimization calls, and this activity caused crashes when a nested optimization request was required. These problem was resolved by ensuring that GPORCA falls back to the Postgres planner when nested optimization requests are required.

Release 5.29.4

Resolved Issues

The listed issues are resolved in Greenplum Database 5.29.4.

For issues resolved in prior 5.x releases, refer to the corresponding release notes. Release notes are available from the Greenplum page on VMware Tanzu Network.

31936, 31913 - Data Flow

In certain cases, an INSERT operation performed on a gpfdist external writable table both did not write the complete data set and reported no error. This issue is resolved; gpfdist now correctly reports and completes error processing when it encounters a retry failure due to poor network conditions.

Release 5.29.3

Resolved Issues

The listed issues are resolved in Greenplum Database 5.29.3.

For issues resolved in prior 5.x releases, refer to the corresponding release notes. Release notes are available from the Greenplum page on VMware Tanzu Network.

31884 - Query Optimizer, Server:Execution

Resolves an issue where the Query Optimizer generated a plan for a query that included a subquery ALL construct that could generate incorrect results or crash during execution.

9649 - Server

Resolves an issue where a PANIC error occurred intermittently when a query waiting on a resource queue was canceled.

Release 5.29.2

Changed Features

Greenplum Database 5.29.2 includes these changes:

  • Greenplum Streaming Server (GPSS) version 1.4.3 is included, which includes changes and bug fixes. Refer to the GPSS Release Notes for more information on release content and to access the GPSS documentation.

Note: If you have previously used GPSS in your Greenplum 5.x installation, you may be required to perform upgrade actions as described in Upgrading the Streaming Server. - The PXF version 6.2.1 distribution is available with this release; you can download it from the Tanzu Greenplum release version 5.29.2 Release Download directory named Greenplum Platform Extension Framework on VMware Network. Refer to the PXF documentation for information about this release and for installation instructions. - The metrics collector included with Greenplum 5.29.2 was updated to support Greenplum Command Center 4.14.0, which resolves several issues. Greenplum Command Center versions prior to version 4.14.0 are not supported with Greenplum 5.29.2 and later releases. - Greenplum Text version 3.8.1 is available with this release; you can download it from the Tanzu Greenplum release version 5.29.2 Release Download directory named Greenplum Advanced Analytics on VMware Tanzu Network. Refer to the Greenplum Text Documentation.

Resolved Issues

The listed issues are resolved in Tanzu Greenplum Database 5.29.2.

For issues resolved in prior 5.x releases, refer to the corresponding release notes. Release notes are available from the Tanzu Greenplum page on Tanzu Network.

Postgres CVE fixes

This release backports the following Postgres CVE fixes:

  • CVE-2021-23214: Server processes unencrypted bytes from man-in-the-middle.
  • CVE-2021-23222: libpq processes unencrypted bytes from man-in-the-middle.

572 - Greenplum Installation

Resolved an issue with the rpm installers, so installing Greenplum does not overwrite the symlink if the install file is for a different major version.

31768 - Data Flow

Resolved an issue where gpload> was reporting the error No such file or directory",,,,,,"CREATE EXTENSION IF NOT EXISTS dataflow; when connecting to a Greenplum Database 5.x. This fix checks the Greenplum version to determine whether it should create a new extension.

31887 - Server

Resolves a resource queue issue where a session with multiple active portals did not decrement the active statement count following a deadlock report or statement cancellation.

31896 - Optimizer

Using set operators (the EXCEPT clause) could cause crashes during query execution. This occurred because GPORCA did not add required scalar casts for input columns when the types did not match the output types of the set operation. GPORCA was modified to add the required scalar casts.

Release 5.29.1

Resolved Issues

The listed issues are resolved in Tanzu Greenplum Database 5.29.1.

For issues resolved in prior 5.x releases, refer to the corresponding release notes. Release notes are available from the Tanzu Greenplum page on Tanzu Network.

31825 - Server

Certain relfiles were incorrectly zeroed out after running a full gprecoverseg, caused by the resync manager skipping these relfiles. Logging has been improved in order to find out the root cause of this issue.

31817 - Server

This fix introduces a new GUC gp_enable_drop_key_constraint_child_partition wihch provides a way to drop the primary/unique key directly from child partitions.

31789 - Server

Enabling the GUC log_hostnames with gpconfig generated WARNING log messages. This issue is now resolved.

179159922 - Server

Greenplum Database would initialize the pg_aocsseg table entries with frozen tuples to ensure these entries were implicitly visible even after a rollback. This strategy created issues with the roll back of Append Optimized Columnar (AOC) tables. This issue has now been resolved.

Release 5.29.0

New Features

Greenplum Database 5.29.0 includes these new features:

  • Greenplum 5.29.0 introduces a new Query Optimizer server configuration parameter, optimizer_xform_bind_threshold. You can use this parameter to reduce the optimization time and overall memory usage of queries that include deeply nested expressions by specifying the maximum number of bindings per transform that GPORCA produces per group expression.
  • The gpload utility was updated to use the same code and feature set that is included with gpload in Tanzu Greenplum 6.x releases. This update adds the --max_retries option to specify the number of times the utility attempts to connect to Greenplum Database after a connection timeout. The default value, 0, does not attempt a connection after a timeout.

This version of the gpload also provides additional error information for cases where staging tables cannot be created. - The license file for the Windows Client and Loader Tools Package was updated to the latest version.

Resolved Issues

The listed issues are resolved in Tanzu Greenplum Database 5.29.0.

For issues resolved in prior 5.x releases, refer to the corresponding release notes. Release notes are available from the Tanzu Greenplum page on Tanzu Network.

31736 - Resource Queues

Due to improper error handling, Greenplum Database raised a duplicate portal identifier warning that was in some cases immediately followed by an out of shared memory error. This issue is resolved; Greenplum Database now raises distinct errors for duplicate portal identifier and out of shared memory.

31727, 31736 - Server

When the log_lock_waits GUC was enabled it resulted in spurious deadlock reports and orphaned wait queue states which, in turn, could lead to memory corruption of certain internal tables. This issue can be resolved by disabling the log_lock_waits GUC.

31725 - Server

In some cases, Greenplum Database generated a PANIC when the user cancelled a query on an AO table due to a double free of a visimap object. This issue is resolved.

31708 - Catalog and Metadata

Resolves an issue where a non-superuser who ran VACUUM FULL on a table that they had no permission to access could block further access to the table by currently running transactions. Greenplum Database now performs the permission check before it acquires a lock on the table.

31617 - Server

A database instance was failing to start up, with the message Command pg_ctl reports Master gdm instance active because a mirror segment couldn’t be recovered. This was due to the incorrect type of lock being used when creating or altering a resource group. This issue is resolved.

31466 - gpload

Resolved an issue where gpload would fail with column names that used uppercase or mixed-case characters. gpload now automatically adds double quotes to column names that are not already quoted in the YAML control file.

Beta Features

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

Warning: Beta features are not supported for production deployments.

Greenplum Database 5.29.6 includes these Beta features:

SuSE 12 resolves the Linux cgroup issues that caused the performance degradation when Greenplum Database resource groups are enabled.

Deprecated Features

Deprecated features will be removed in a future major release of Greenplum Database. Tanzu Greenplum 5.x deprecates:

  • The --skip_root_stats option to analyzedb (deprecated since 5.18).

If the option is specified, a warning is issued stating that the option will be ignored. - The gptransfer utility (deprecated since 5.17).

The utility copies objects between Greenplum Database systems. The gpcopy utility provides gptransfer functionality. - The gphdfs external table protocol (deprecated since 5.17).

Consider using the Greenplum Platform Extension Framework (PXF) pxf external table protocol to access data stored in an external Hadoop file system. Refer to Accessing External Data with PXF for more information. - The server configuration parameter gp_max_csv_line_length (deprecated since 5.11).

For data in a CSV formatted file, the parameter controls the maximum allowed line length that can be imported into the system). - The server configuration parameter gp_unix_socket_directory (deprecated since 5.9).

Note: Do not change the value of this parameter. The default location is required for Greenplum Database utilities. - Support for Data Domain Boost 3.0.0.3 (deprecated since 5.2).

The DELL EMC end of Primary Support date is December 31, 2017. - These unused catalog tables (deprecated since 5.1):

  • gp_configuration
  • gp_db_interfaces
  • gp_interfaces
  • The gpcrondump and gpdbrestore utilities (deprecated since 5.0).
  • The gpcheck utility (deprecated since 5.0).

Known Issues and Limitations

Tanzu Greenplum 5.x has these limitations:

  • Upgrading a Greenplum Database 4.3.x release to Tanzu Greenplum 5.x is not supported. See Migrating Data to Tanzu Greenplum 5.x.
  • Some features are works-in-progress and are considered to be Beta features. VMware does not support using Beta features in a production environment. See Beta Features.
  • Greenplum Database 4.3.x packages are not compatible with Tanzu Greenplum 5.x.

The following table lists key known issues in Tanzu Greenplum 5.x.

Table 1. Key Known Issues in Tanzu Greenplum 5.x

Issue Category Description
31881 gpload gpload returns the error: 1. could not open extension control file … dataflow.control when it erroneously tries to register the dataflow extension. Ignore the error.
11143 gpinitsystem If a stale .gphostcache file exists in a user’s home directory, then gpinitsystem fails with an error similar to: [FATAL]:-Unable to contact <name>: ping: cannot resolve <name>: Unknown host <name>: getaddrinfo — nodename nor servname provided, or not known Script Exiting! Workaround: Delete the .gphostcache file and retry the initialization command.
n/a RPM Installation When you use yum or rpm to upgrade to Greenplum Database 5.28.0 or later, a bug in the older RPM packaging removes the symbolic link (for example, /usr/local/greenplum-db) that would normally point to the version-specific directory. This problem does not occur for new installations, or when upgrading from 5.28.x to a later version. Workaround: After first upgrading to 5.28.0 or later, manually create the symbolic link to point to the new version directory. For example, if you installed Greenplum to the default directory: 1. $ sudo ln -s /usr/local/greenplum-db-5.29.6 /usr/local/greenplum-db
30537 Postgres Planner The Postgres Planner generates a very large query plan that causes out of memory issues for the following type of CTE (common table expression) query: the WITH clause of the CTE contains a partitioned table with a large number partitions, and the WITH reference is used in a subquery that joins another partitioned table. Workaround: If possible, use the GPORCA query optimizer. With the server configuration parameter optimizer=on, Greenplum Database attempts to use GPORCA for query planning and optimization when possible and falls back to the Postgres Planner when GPORCA cannot be used. Also, the specified type of query might require a long time to complete.
30420 Postgres Planner Greenplum Database 5 generates a PANIC for some queries that use the aggregate function percentile_cont(). Workaround: Setting the server configuration parameter gp_idf_deduplicate to force eliminates the PANIC. Note: The issue does not occur in Greenplum Database 6. Also, the server configuration parameter gp_idf_deduplicate has been removed in Greenplum Database 6.
N/A PXF PXF is available only for supported Red Hat and CentOS platforms. PXF is not available for supported SuSE platforms.
9460 CREATE UNIQUE INDEX When you create a unique index on a partitioned table, Greenplum Database does not check to ensure that the index contains the table partition keys, which are required to enforce uniqueness. Workaround: To avoid duplicate rows, manually specify partition keys when executing CREATE UNIQUE INDEX on a partitioned table.
3290 JSON The to_json() function is not implemented as a callable function. Attempting to call the function results in an error. For example: 1. tutorial=# select to_json(‘Fred said “Hi.”‘::text); 2. ERROR: function to_json(text) does not exist 3. LINE 1: select to_json(‘Fred said “Hi.”‘::text); 4. ^ 5. HINT: No function matches the given name and argument 6. types. You might need to add explicit type casts. Workaround: Greenplum Database invokes to_json() internally when casting to the json data type, so perform a cast instead. For example: SELECT ‘{“foo”:”bar”}’::json; Greenplum Database also provides the array_to_json() and row_to_json() functions.
29064 Storage: DDL The money data type accepts out-of-range values as negative values, and no error message is displayed. Workaround: Use only in-range values for the money data type (32-bit for Greenplum Database 4.x, or 64-bit for Greenplum Database 5.x). Or, use an alternative data type such as numeric or decimal.
29139 DML In some cases for an append-optimized partitioned table, Greenplum Database acquires a ROW EXCLUSIVE lock on all leaf partitions of the table when inserting data directly into one of the leaf partitions of the table. The locks are acquired the first time Greenplum Database performs validation on the leaf partitions. When inserting data into one leaf partition, the locks are not acquired on the other leaf partitions as long as the validation information remains in memory. The issue does not occur for heap-storage partitioned tables.
29246 gpconfig When querying the gp_enable_gpperfmon server configuration parameter with gpconfig -s gp_enable_gpperfmon, gpconfig always reports off, even when the parameter has been set to on correctly, and the gpmmon and gpsmon agent processes are running. Workaround: To see if gpperfmon is enabled, check the value of the gp_enable_gpperfmon configuration parameter in the postgresql.conf file or use the ps command to look for the gpmmon (master) or gpsmon (segment) processes.
29351 gptransfer The gptransfer utility can copy a data row with a maximum length of 256 MB.
29395 DDL The gpdbrestore or gprestore utility fails when the utility attempts to restore a table from a backup and the table is incorrectly defined with duplicate columns as distribution keys. The issue is caused when the gpcrondump or gpbackup utility backed up a table that is incorrectly defined. The CREATE TABLE AS command could create a table that is incorrectly defined with a distribution policy that contains duplicate columns as distribution keys. The CREATE TABLE ISSUE has been resolved. Now the CREATE TABLE AS command does not create the specified type of table. The command returns an error. However, restore operations will continue to fail if you try to restore the incorrectly defined tables from a backup.
29485 Catalog and Metadata When a session creates temporary objects in a database, Greenplum Database might not the drop temporary objects when the session ends if the session terminates abnormally or is terminated from an administrator command.
29496 gpconfig For a small number of server configuration parameters such as log_min_messages, the command gpconfig -s <config_param> does not display the correct value of the parameter for the segment hosts when the value of the parameter on master is different than the value on the segments. For parameters with the set classification master, the utility displays the value set on the master for both master and segments (for information about set classifications, see Setting Parameters in the Tanzu Greenplum Database Documentation). For those parameters, the value on the master is passed as part of queries to segment instances. The SQL query that gpconfig runs to display the master and segment parameter values returns the master host value that is passed to the segment as part of the query. For a few parameters such as log_min_messages, segment instances use the segment host value specified in the postgresql.conf file at start up. The segment value can overridden for the scope of a query. Workaround: To display the parameter value specified in the postgresql.conf file on the master host and segment hosts, you can specify the gpconfig option —file.
29523 gptoolkit An upgrade between minor releases does not update the template0 database, and in some cases, using these views in the gp_toolkit schema might cause issues if you create a database using template0 as the template database after you upgrade to Greenplum Database 5.11.0 or later. - The gp_toolkit.gp_bloat_expected_pages view might incorrectly report that a root partition table is bloated even though root partition tables do not contain data if you upgrade from Greenplum Database 5.10.x or earlier. - The gp_toolkit.gp_bloat_diag view might return an integer out of range error in some cases if you upgrade from Greenplum Database 5.3.0 or earlier. For example, the issues might occur if you upgrade a Greenplum Database system from 5.3.0 or an earlier 5.x release and then run a gprestore operation with the —redirect-db option to create a new database. The utility creates a new database using template0 as the template database. Workaround: You can update the views in the gp_toolkit schema in the new database. For information about checking and updating gp_toolkit, see Update for gp_toolkit.gp_bloat_expected_pages Issue and Update for gp_toolkit.gp_bloat_diag Issue.
29674 VACUUM Performing parallel VACUUM operations on a catalog table such as pg_class, gp_relation_node, or pg_type and another table causes a deadlock and blocks connections to the database. Workaround: Avoid performing parallel VACUUM operations on catalog tables and user tables.
29699 ANALYZE In Greenplum Database 5.15.1 and earlier 5.x releases, an ANALYZE command might return a error that states target lists can have at most 1664 entries when performing an ANALYZE operation on a table with a large number of columns (more than 800 columns). The error occurs because the in-memory sample table created by ANALYZE requires an additional column to indicate whether a column is NULL or is a truncated column for each variable length column being analyzed (such as varchar, text, and bpchar, numeric, arrays, and geometric datatype columns). The error is returned when ANALYZE attempts to create a sample table and the number of columns (table columns and indicator columns) exceeds the maximum number of columns allowed. In Greenplum Database 5.16.0 and later 5.x releases, the ANALYZE sample table does not require an additional column for variable length text columns such as varchar, text, and bpchar columns. Workaround: To collect statistics on the table, perform ANALYZE operations on 2 or more sets of table columns.
29766 VACUUM A long-running catalog query can block VACUUM operations on the system catalog until the query completes or is canceled. This type of blocking cannot be observed using pg_locks, and the VACUUM operation itself cannot be canceled until the long-running query completes or is canceled.
29917 Segment Mirroring A “read beyond eof” error has been observed with certain persistent tables during full recovery. The root cause of this problem has not yet been determined. Greenplum Database version 5.21 contains additional debug logging to help in determining the cause of this problem. The additional logging is enabled by default, and adds approximately 646 bytes to each persistent table entry file. If you want to disable the additional debug logging, set the debug_filerep_config_print configuration parameter “false.”
30180 Locking, Signals, Processes The pg_cancel_backend() and pg_terminate_backend() functions might leave some orphan processes when they are used to cancel a running VACUUM command. Workaround: You can stop the orphan processes by restarting the Greenplum Database system.
30207 Catalog and Metadata Defining a unique index on an empty table that is defined with a DISTRIBUTED BY clause might change the table’s distribution policy. Greenplum Database adds any columns specified in the index that are not in the table’s distribution policy to the distribution policy. In Greenplum Database, the columns specified in a unique index must be a left-subset of the table’s distribution policy. If the table is not empty, an error is returned.
148119917 Resource Groups Testing of the resource groups feature has found that a kernel panic can occur when using the default kernel in RHEL/CentOS system. The problem occurs due to a problem in the kernel cgroups implementation, and results in a kernel panic backtrace similar to: 1. [81375.325947] BUG: unable to handle kernel 2. NULL pointer dereference at 0000000000000010[81375.325986] 3. IP: [<ffffffff812f94b1>] rb_next+0x1/0x50 [81375.326014] 4. PGD 0 [81375.326025] Oops: 0000 [#1] SMP [81375.326041] 5. Modules linked in: veth ipt_MASQUERADE nf_nat_masquerade_ipv4 6. iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 7. xt_addrtype iptable_filter xt_conntrack nf_nat nf_conntrack 8. bridge stp llc intel_powerclamp coretemp intel_rapl 9. dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio kvm_intel 10. kvm crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul 11. glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support 12. ses enclosure ipmi_ssif pcspkr lpc_ich sg sb_edac mfd_core 13. edac_core mei_me ipmi_si mei wmi ipmi_msghandler shpchp 14. acpi_power_meter acpi_pad ip_tables xfs libcrc32c sd_mod 15. crc_t10dif crct10dif_generic mgag200 syscopyarea sysfillrect 16. crct10dif_pclmul sysimgblt crct10dif_common crc32c_intel 17. drm_kms_helper ixgbe ttm mdio ahci igb libahci drm ptp 18. pps_core libata dca i2c_algo_bit [81375.326369] i2c_core 19. megaraid_sas dm_mirror dm_region_hash dm_log dm_mod 20. [81375.326396] CPU: 17 PID: 0 Comm: swapper/17 Not tainted 21. 3.10.0-327.el7.x86_64 #1 [81375.326422] Hardware name: Cisco 22. Systems Inc UCSC-C240-M4L/UCSC-C240-M4L, BIOS 23. C240M4.2.0.8b.0.080620151546 08/06/2015 [81375.326459] Workaround: Upgrade to the latest-available kernel for your Red Hat or CentOS release to avoid the above system panic.
149789783 Resource Groups Significant Tanzu Greenplum performance degradation has been observed when enabling resource group-based workload management on Red Hat 6.x, CentOS 6.x, and SuSE 11 systems. This issue is caused by a Linux cgroup kernel bug. This kernel bug has been fixed in CentOS 7.x and Red Hat 7.x systems. When resource groups are enabled on systems with an affected kernel, there can be a delay of 1 second or longer when starting a transaction or a query. The delay is caused by a Linux cgroup kernel bug where a synchronization mechanism called synchronize_sched is abused when a process is attached to a cgroup. See <https://www.spinics.net/lists/cgroups/msg05708.html> and <https://lkml.org/lkml/2013/1/14/97> for more information. The issue causes single attachment operations to take longer and also causes all concurrent attachments to be executed in sequence. For example, one process attachment could take about 0.01 second. When concurrently attaching 100 processes, the fastest process attachment takes 0.01 second and the slowest takes about 1 second. Tanzu Greenplum performs process attachments when a transaction or queries are started. So the performance degradation is dependent on concurrent started transactions or queries, and not related to concurrent running queries. Also Tanzu Greenplum has optimizations to bypass the rewriting when a QE is reused by multiple queries in the same session. Workaround: This bug does not affect CentOS 7.x and Red Hat 7.x systems. If you use Red Hat 6 and the performance with resource groups is acceptable for your use case, upgrade your kernel to version 2.6.32-696 or higher to benefit from other fixes to the cgroups implementation. SuSE 11 does not have a kernel version that resolves this issue; resource groups are still considered to be a Beta feature on this platform. Resource groups are not supported on SuSE 11 for production use.
150906510 Backup and Restore Greenplum Database 4.3.15.0 and later backups contain the following line in the backup files: 1. SET gp_strict_xml_parse = false; However, Greenplum Database 5.0.0 does not have a parameter named gp_strict_xml_parse. When you restore the 4.3 backup set to the 5.0.0 cluster, you may see the warning: 1. [WARNING]:-gpdbrestore finished but ERRORS were found, 2. please check the restore report file for details Also, the report file may contain the error: 1. ERROR: unrecognized configuration 2. parameter “gp_strict_xml_parse” These warnings and errors do not affect the restoration procedure, and can be ignored.
151135629 COPY command When the ON SEGMENT clause is specified, the COPY command does not support specifying a SELECT statement in the COPY TO clause. For example, this command is not supported. 1. COPY (SELECT FROM testtbl) 2. TO ‘/tmp/mytst<SEGID>’ ON SEGMENT
158011506 Catalog and Metadata In some cases, the timezone used by Greenplum Database might be different than the host system timezone, or the Greenplum Database timezone set by a user. In some rare cases, times used and displayed by Greenplum Database might be slightly different than the host system time. The timezone used by Greenplum Database is selected from a set of internally stored PostgreSQL timezones. Greenplum Database selects the timezone by matching a PostgreSQL timezone with the user specified time zone, or the host system time zone. For example, when selecting a default timezone, Greenplum Database uses an algorithm to select a PostgreSQL timezones based on the host system timezone. If the system timezone includes leap second information, Greenplum Database cannot match the system timezone with a PostgreSQL timezone. Greenplum Database calculates a best match with a PostgreSQL timezone based on information from the host system. Workaround: Set the Greenplum Database and host system timezones to a timezone that is supported by both Greenplum Database and the host system. For example, you can show and set the Greenplum Database timezone with the gpconfig utility. These commands show the Greenplum Database timezone and set the timezone to US/Pacific. 1. # gpconfig -s TimeZone 1. # gpconfig -c TimeZone -v ‘US/Pacific’ You must restart Greenplum Database after changing the timezone. The command gpstop -ra restarts Greenplum Database. The Greenplum Database catalog view pg_timezone_names provides Greenplum Database timezone information.
162317340 Client Tools On Tanzu Network in the file listings for Greenplum Database releases between 5.7.1 and 5.14.0, the Greenplum Database AIX Client Tools download file is incorrectly labeled as Loaders for AIX 7. The file you download is the correct AIX 7 Client Tools file.
163807792 gpbackup/ gprestore When the % sign was specified as the delimeter in an external table text format, gpbackup escaped the % sign incorrectly in the CREATE EXTERNAL TABLE command. This has been resolved. The % sign is correctly escaped.
164671144 gpssh-exkeys The gpssh-exkeys utility uses the Paramiko SSH library for Python, which has a dependency on the Python Cryptography Toolkit (PyCrypto) library. The following security vulnerabilities have been identified in some versions of PyCrypto. - <https://nvd.nist.gov/vuln/detail/CVE-2018-6594> - lib/Crypto/PublicKey/ElGamal.py in PyCrypto through 2.6.1 generates weak ElGamal key parameters, which allows attackers to obtain sensitive information by reading ciphertext data (i.e., it does not have semantic security in face of a ciphertext-only attack). The Decisional Diffie-Hellman (DDH) assumption does not hold for PyCrypto’s ElGamal implementation. Paramiko does not import this algorithm, so Greenplum Database is unaffected by this vulnerability. - <https://nvd.nist.gov/vuln/detail/CVE-2013-7459> - Heap-based buffer overflow in the ALGnew function in block_templace.c in Python Cryptography Toolkit (aka pycrypto) allows remote attackers to execute arbitrary code as demonstrated by a crafted iv parameter to cryptmsg.py. This bug was introduced in PyCrypto 2.6. Greenplum Database has PyCrypto 2.0.1, and is unaffected by the vulnerability. - <https://nvd.nist.gov/vuln/detail/CVE-2013-1445> - The Crypto.Random.atfork function in PyCrypto before 2.6.1 does not properly reseed the pseudo-random number generator (PRNG) before allowing a child process to access it, which makes it easier for context-dependent attackers to obtain sensitive information by leveraging a race condition in which a child process is created and accesses the PRNG within the same rate-limit period as another process. Paramiko version 1.7.6-9, used in Greenplum Database 4.x and 5.x, introduced a workaround to this bug. Paramiko version 1.18.4 in Greenplum Database 6 solves it in a more permanent way. - <https://nvd.nist.gov/vuln/detail/CVE-2012-2417> - PyCrypto before 2.6 does not produce appropriate prime numbers when using an ElGamal scheme to generate a key, which reduces the signature space or public key space and makes it easier for attackers to conduct brute force attacks to obtain the private key. Paramiko does not import this algorithm, so Greenplum Database is unaffected by the vulnerability. Through testing and investigation, VMware has determined that these vulnerabilities do not affect Greenplum Database, and no actions are required for existing Greenplum Database 4.3 or 5.x releases. However, there may be additional unidentified vulnerabilities in the PyCrypto library, and users who install a later version of PyCrypto could be exposed to other vulnerabilities. The PyCrypto library will be removed from Greenplum Database 6.0. Workaround: Administrators can set up passwordless SSH between hosts in the Greenplum Database cluster without using the gpssh-exkeys utility. This must be done before initializing the Greenplum Database system. 1. Create an SSH key for the gpadmin user on each host. For example, log in to each host as gpadmin and use the ssh-keygen command to generate an SSH key. Do not enter a passphrase. 2. Add the public key for each host in the cluster to every other host in the cluster. For example, use the ssh-copy-id command from each host to copy the public key to every other host in the cluster. When adding new hosts to the Greenplum Database system, you must create a new SSH key for each new host and exchange keys between the existing hosts and new hosts.
165434975 search_path An identified PostgreSQL security vulnerability (<https://nvd.nist.gov/vuln/detail/CVE-2018-1058>) also exists in Greenplum Database. The problem centers around the default public schema and how Greenplum Database uses the search_path setting. The ability to create objects with the same names in different schemas, combined with how Greenplum Database searches for objects within schemas, presents an opportunity for a user to modify the behavior of a query for other users. For example, a malicious user could insert a trojan-horse function that, when executed by a superuser, grants escalated privileges to the malicious user. There are methods to protect from this vulnerability. See A Guide to CVE-2018-1058: Protect Your Search Path on the PostgreSQL wiki for a full explanation of the vulnerability and the steps you can take to protect your data.
168142530 Backup and Restore Backups created on Greenplum Database versions before 4.3.33.0 or 5.1.19.0 may fail to restore to Greenplum Database versions 4.3.33.0 or 5.1.19.0 or later. In Greenplum Database 4.3.33.0 and 5.1.19.0, a check was introduced to ensure that the distribution key for a table is equal to the primary key or is a left-subset of the primary key. If you add a primary key to a table that contains no data, Greenplum Database automatically updates the distribution key to match the primary key. The index key for any unique index on a table must also match or be a left-subset of the distribution key. Earlier Greenplum Database versions did not enforce these policies. Restoring a table from an older backup that has a different distribution key causes errors because the backup data file on each segment contains data that was distributed using the original distribution key. Restoring a unique index with a key that does not match the distribution key will fail with an error when attempting to creat

（本文超出站点单文档体积上限，已截断）