Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Issue

Component

Description

Setting a row-based access policy on an underlying table of a view denies the user access to the view.

This issue is fixed.

Occasionally, an empty response from S3 (response code 0) could cause some database operations to fail.

This issue has been fixed.

Due to a miscalculation, license auditor running in sampling mode showed a much larger standard error than it actually was (this is the number you see after the +/- sign on the data size line in license compliance messages).

This issue has been fixed.

Running the remove task using a vbr config file with an incorrect "snapshotName" removed entries from the backup manifest file. This problem has been resolved.

License usage was showing 0% when Autopass license is used. This issue has been fixed.

Vertica server hotfix upgrade is also required for this fix to take effect (same release number).

When the Management Console on premises attempted to download the Vertica AMI repository file, an error occurred. The error did not cause any functionality failures since the repository file is not used for MC on premises.

This issue has been fixed.

Management Console on AWS did not display the AMI version which may have caused user confusion if the MC was not hotfixed on a Vertica hotfix AMI.

This issue has been fixed.

Hive file formats partition pruning requires all partition directory names to be in lower-case. Previously, Export to Parquet sometimes generated partition directory names in mixed-case. This caused the partition pruning optimization to be skipped on a load.

This issue has been fixed.

If vertica.conf has a parameter set to a value that starts with hash (#), Vertica ignores that parameter and logs a warning.

This issue has been fixed.

Adding large numbers of nodes in a single operation could lead to an admintools error parsing output.

This issue has been fixed.

Issue

Component

Description

At times, Management Console failed to add a new host to the database after a long wait.

This issue has been fixed.

The Database Designer wizard in Management Console did not correctly set the default value for design k-safety.

This issues has been fixed.

In some regex scalar functions, Vertica would crash for certain long input strings.

This issue has been fixed.

Download Event history was not working in Internet Explorer.

This issue has been fixed.

Having frequent create/insert/drop tables caused a memory leak in the catalog.

This issue has been fixed.

In the Management Console, the Eon mode database could not be provisioned due to inconsistent versions between the Management Console AMI and the Vertica database.

This issue has been fixed.

Management Console could not import multiple clusters when the host had the same private IP address as the private IP address of a previously imported cluster.

This issue has been fixed.

Issue

Component

Description

When HCatalogConnectorUseHiveServer2 was set to 0, the database failed to start.

This issue has been fixed.

Very large expressions could run out of stack and crash the node.

This issue has been fixed.

If a control node and one of its child nodes went down, attempts to restart the second (child) node sometimes failed.

This issue has been fixed.

At times, FJsonParser array parsing behavior returned inconsistent results.

This issue has been fixed.

The SKIP keyword of a COPY statement was not properly supported with the FIXEDWIDTH data format.

This issue has been fixed.

If you ran APPROXIMATE_COUNT_DISTINCT_SYNOPSIS on a database table that contained NULL values, the synopsis object that it returned sometimes was larger than the one it returned after the NULL values were removed.

This issue has been resolved.

A new Aggregate function, LISTAGG denormalizes rows into a string of comma-separated values or other human-readable formats.

Vertica now supports full backup and restore for Eon Mode databases.

Issue

Component

Description

Occasionally, the EXPORT TO PARQUET command wrote data to incorrect partition directories of data types timestamp, date, and time.

This issue has been fixed.

Query performance was sometimes sub-optimal if the query included a subquery that joined multiple tables in a WHERE clause, and the parent query included this subquery in an outer join that spanned multiple tables.

This issue has been fixed.

When a projection was created with only the "PINNED" keyword, Vertica incorrectly considered it a segmented projection. This caused optimizer internal errors and incorrect results when loading data into tables with these projections.

This issued has been fixed.

IMPORTANT: The fix only applies to newly created pinned projections. Existing pinned projection in the catalog are still incorrect and need to be dropped and recreated manually.

Previously, export to Parquet generated boolean partition values that could not be loaded correctly.

This issue has been fixed.

Long queries were failing in the Management Console Query Execution page.

This issue has been fixed.

Issue

Component

Description

Add Column Not Null gets transformed into two different statements: Alter Table Add Column and Alter Table Add Constraint.

The second statement can fail and results in a new column in your table but missing the constraint. It also produces a confusing rollback message that doesn't indicate that the column was added anyway.

The fix is to deal with Add Column Not Null in a same statement.

Queries involving a join of two external tables loading parquet files sometimes caused Vertica to crash. The crash happened in a very rare situation due to memory misalignment.

This issue has been fixed.

If a Parquet file metadata is very large, Vertica can consume more memory than reserved and crash when the system runs out of memory.

This issue has been fixed.

Certain large Parquet files generated from ParquetExport could contain a lot of metadata leading to out of memory issues.

A new parameter 'fileSizeMB' has been added to ParquetExport to limit the file sizes being exported, thereby limiting the metadata size.

In a COPY statement, excessively long invalid inputs to any date or time columns could cause stack overflows, resulting in a crash.

This issue has been fixed.

Previously, query label only applied to CTAS statements, but was missing in the implicit INSERT SELECT statement.

With this fix, query label will be applied to both statements.

Issue

Component

Description

Vertica crashed when a function expression was assigned an alias with the same name as one of the ILM operations: copy_table, copy_partitions_to_table, move_partitions_to_table and swap_partitions_between_tables.

This issue is fixed.

Before this release, S3Export was not thread safe when the data contains time/date values. This means S3Export should not be used with PARTITION BEST when exporting time/date values before this fix.

If the Vertica Management Console was deployed in AWS using the Basic or Advanced CFT and a non-zero CIDR (e.g., 2.22.222.22/32), then using the MC to revive a database failed with the error Cannot get initial Revive DB information from the Agent.

This issue has been resolved.

Issue

Component

Description

If you tried to insert data that was too wide for a VARCHAR or VARBINARY column, the error message did not specify the column name. This error message now includes the column name.

COPY statements using the default parser could erroneously reject rows if the input data contained overflowing floating point values in one column and the maximum 64-bit integer value in another column. This issue has been fixed.

Issue

Component

Description

Sometimes CLEAR_DATA_DEPOT() does not clear all the data on one or more nodes.

AutoPass format licenses do not work properly when installed in Vertica 8.1 or older. To replace these licenses with legacy Vertica license, users need to set the following parameter:

AllowVerticaLicenseOverWriteHP=1

APPLY_SVD and APPLY_PCA functions are implemented as User-Defined Transform Functions (UDTFs). A query containing a UDTF that takes many input columns (e.g. more than 1000) and also returns many columns may fail with the error "Request size too big" due to additional memory requirement in parsing.

Workaround: Increase the value of configuration parameter MaxParsedQuerySizeMB or reduce the number of output columns. For APPLY_SVD and APPLY_PCA, you can limit the number of output columns either by setting the parameter num_components or by setting the parameter cutoff. In practice, cutoff=0.9 is usually enough.

Note that If you increase MaxParsedQuerySizeMB to a larger value, for example 4096, each query you run may use 4 GB of memory during parsing. This means that running multiple queries at the same time could cause out-of-memory (OOM) issues if your total memory is limited. Please refer to the Vertica documentation for more information about MaxParsedQuerySizeMB.

Partition operations that use a range, for example, copy_partitions_to_table, must split storage containers that span the range in order to complete. For tables partitioned using a GROUP BY expression, such split plans can require a relatively large amount of memory, especially when the table has a large number of columns. In some cases, the partition operation may error with "ERROR 3587: Insufficient resources to execute plan on pool <poolname>".

Workaround: Increase the memorysize or decrease the plannedconcurrency of <poolname>.

Hint: A best practice is to group partitions so that it is never necessary to split storage containers. Following this guidance greatly improves the performance of most partition operations.

A transaction that started before a node began recovery is referred to as a dirty transaction in the context of recovery. A recovering node must wait for, or cancel, such a transaction to recover tables modified by the transaction. In some rare instances such transactions may hang and cannot be canceled. Tables locked by such a transaction can not be recovered and therefore a recovering node cannot transition to 'UP'. Usually, the hung transaction can be stopped by restarting the node on which the transaction was initiated, assuming this is not a critical node. In extreme cases or instances where the initiator node is a critical node, the cluster must be restarted.

On some systems, occasionally admintools will not be able to parse the output it sees while running SSH commands on other hosts in the cluster. The issue is typically transient. There is no known work-around.

On some systems admintools cannot parse output while running SSH commands on hosts in the cluster. In some situations, if the admintools operation needs to run on just one node, there is a workaround. Users can avoid this issue by using SSH to connect to the target node and running the admintools command on that node directly.

On databases with hundreds of storage locations, admintools SSH communication buffers can overflow. The overflow can interfere with database operations like startup and adding nodes. There is no known workaround.

When trying to revive the cluster, sometimes Vertica returns a "file not found" error. In most cases, this is just an intermittent error so the workaround is to try revive again.

A PANIC happens when an object restore transaction involves the following:

- Has flatten table(s) to be restored.

- Is canceled at the middle of the transaction.

When hcatalogconnector schemas are created with custom_partitions enabled, poor performance has been observed when there are many (500+) partitions. By default, custom_partitions is disabled on hcatalogconnector schemas.

TM operations, such as moveout or re-partitioning, of an unsegmented projection may error out when a concurrent re-balance operation removes the projection from the node.

If the EncryptSpreadComm parameter is set to 'vertica' on a SUSE Linux Enterprise Server (SLES) 11 cluster, Vertica fails to start. Vertica has deprecated support for SLES 11 and will remove support in a later release.

Workaround: Delete the setting for EncryptSpreadComm.

Issuing a query that returns a large result set and closing the statement before retrieving all of its rows can result in the following error when attempting subsequent operations with the statement:

"An error occurred during query preparation: Multiple commands cannot be active on the same connection. Consider increasing ResultBufferSize or fetching all results before initiating another command."

Workaround: Set the ResultBufferSize property to 0 or retrieve all rows associated with a result set before closing the statement.

Issue

Component

Description

In past releases, Vertica placed an exclusive lock on the global catalog while it created a query plan for CREATE TABLE AS <query>. Very large queries could prolong this lock until it eventually timed out. On rare occasions, the prolonged lock caused an out-of-memory exception that shut down the cluster.

This problem was resolved by moving the query planning process outside the scope of catalog locking.

In some workloads, the memory consumed by a long-running session could grow over time.

This has been resolved.

Issue

Component

Description

Applying an access policy on some columns in a table significantly impacted execution of updates on that table, even where the query excluded the restricted columns. Further investigation determined that the query planner materialized unused columns, which adversely affected overall performance.

This problem has been resolved.

Some versions of Vertica allowed projections to be defined with a subquery that referenced a view or another projection. These malformed projections occasionally caused the database to shut down.

Vertica now detects these errors when it parses the DDL and returns with a message that projection FROM clauses must only reference tables.

Scrutinize was collecting the logs only on the node where it was executed, not on any other nodes.

This issue has been fixed.

Optimized MERGE was, at times, not used with NULL constants in Varchar or Numeric columns.

This issue has been fixed.

With LDAP authentication turned on, users added before LDAP "default search path" modified were not able to logon.

This issue has been fixed.

Object replication and restore left behind temporary files in the database Snapshot folder.

This fix ensures such files are properly cleaned-up when the operation completes.

COPY statements using the default parser could erroneously reject rows if the input data contained overflowing floating point values in one column and the maximum 64-bit integer value in another column.

This issue has been fixed.

Loads and copies from HDFS occasionally failed if Vertica was reading data through libhdfs++ when the NameNode abruptly disconnected from the network. libhdfs++ was being compiled with a debug flag on, which caused network errors to be caught in debug assertions rather than normal error handling and retry logic.

This issue has been fixed.

The ORC Parser skipped rows when the predicate "IS NULL" was applied on a column containing all NULLs.

This issue has been fixed.

INSERT DIRECT failed when configuration parameter ReuseDataConnections was set to 0 (disabled). When this parameter was disabled, no buffer was allocated to accept inserted data.

Now, a buffer is always allocated to accept data regardless of how ReuseDataConnections is set.

Object replication to a target database with a newer version failed during the catalog preprocessing phase when the source and destination cluster had different node names.

This issue has been fixed.

An Internal Error sometimes occurred in queries with subqueries contaning a mix of outer and inner joins.

This issue has been fixed.

Issue

Component

Description

Using an ML function, which accepts a model as a parameter in the definition of a view, and then feeding that view into another ML function as its input relation caused failures in some special cases.

This issue has been fixed.

There was an issue loading from the default region (us-east-1) in some cases where the communal location was in a different region.

This issue has been fixed.

Including certain functions like nvl in a grouping function argument resulted in a "Grouping function arguments need to be group by expressions" error.

This issue has been fixed

Attempts to swap partitions between flattened tables that were created in different versions of Vertica failed, due to minor differences in how source and target SET USING columns were internally defined.

This issue has been fixed.

Hadoop impersonation status messages were not being properly logged.

This issue has been fixed to allow informative messages at the default logging level.

Issue

Component

Description

Export to Parquet using local disk non-deterministically failed in some situations with a 'No such file or directory' error message.

This issue has been fixed.

The way null values were detected for float data type columns returned inconsistent results for some queries with median and percentile functions.

This issue has been fixed.

Dependent index tables did not have their reference indices updated when the base table's columns were altered but not removed. This caused an internal error on reference.

This issue has been fixed so the indices are updated when you alter the base table's columns.

If you tried to insert data that was too wide for a VARCHAR or VARBINARY column, the error message did not specify the column name.

This error message now includes the column name.

Issue

Component

Description

When creating an Eon Mode database through Management Console on an AWS cluster, entering a valid communal storage location and selecting IAM Role authentication did not enable the Next button.

This issue occurred only during database creation, not when creating an Eon Mode database cluster.

This issue has been fixed.

In the Database and Clusters > VerticaDB activity > Detail screen of an Eon database, some column text was not properly formatted.

This issue has been fixed.

An internal EE error occurred when running several query retries and, at the same time, sequence objects referenced in the query were dropped and re-created.

This issue has been fixed so the retried query now picks up the re-created sequence.

When entering the Communal Storage URL for an Eon Mode database in the Management Console, some invalid forms of the URL were allowed.

This issue has been fixed.

In the Vertica Management Console (MC) in AWS, with some Vertica BYOL licenses, when using Cluster Management to add an instance to a Vertica database cluster, you were prompted to upload a license file even if your Premium Edition license is already installed. In the Add Instance wizard, you saw the message 'Your database exceeds the free Community Edition limits, please upload a valid Premium Edition license'.

This issue has been fixed

Issue

Component

Description

Backups to S3 failed when both of the following occurred:

• You backup to the root of the S3 bucket.
• The backup location reaches the restorePointLimit.

This issue has been fixed.

The default value of MaxParsedQuerySizeMB has changed. The original default was 512MB. This only bound a certain amount of "used" parse memory. The default is now 1024MB. This results in bounding all parse memory. There may be some queries that used to be able to run successfully, that will now encounter the "Request size too big. Please try to simplify the query" error. This is not a regression.

To successfully run the query, increase the value of MaxParsedQuerySizeMB and reset the session.

Issue

Component

Description

In very rare circumstances, if a Vertica process crashes during shutdown, the remaining processes might hang indefinitely.

Workaround: The remaining processes can be killed using admin tools.

AutoPass format licenses do not work properly when installed in Vertica 8.1 or older. In order to replace them with legacy Vertica license, users need to set AllowVerticaLicenseOverWriteHP=1.

Export to Parquet using local disk can non-deterministically fail in some situations, with "No such file or directory". Re-running the same export will likely succeed.

A transaction that started before a node began recovery is referred to as a dirty transaction in the context of recovery. A recovering node must wait for or cancel such a transaction in order to recover tables modified by the transaction. In rare instances such transactions may be hung and can not be canceled. Tables locked by such a transaction can not be recovered and therefore a recovering node can not transition to 'UP'. Usually you can stop the hung transaction by restarting the node on which the transaction was initiated, assuming this is not a critical node. In extreme cases or instances where the initiator node is a critical node the cluster must be restarted.

On some systems, occasionally admintools cannot parse the output it sees while running SSH commands on other hosts in the cluster. The issue is typically transient. There is no known work-around.

On databases with hundreds of storage locations, admintools SSH communication buffers can overflow. The overflow can interfere with database operations like startup and adding nodes. There is no known work-around.

On some systems admintools cannot parse output while running SSH commands on hosts in the cluster. We do not know the root cause of this issue. In some situations, if the admintools operation needs to run on just one node, there is a workaround. Users can avoid this issue by using SSH to connect to the target node and running the admintools command on that node directly.

Partition operations that use a range, for example, COPY_PARTITIONS_TO_TABLE must split storage containers that span the range in order to complete. For tables partitioned using a GROUP BY, expression such split plans can require a relatively large amount of memory, especially when the table has a large number of columns. In some cases the partition operation may error with "ERROR 3587: Insufficient resources to execute plan on pool <poolname>".

Workaround: Increase the memorysize or decrease the plannedconcurrency of <poolname>.

Hint: A best practice is to group partitions such that it is never necessary to split storage containers. Following this guidance greatly improves the performance of most partition operations.

The APPLY_SVD and APPLY_PCA functions are implemented as User-Defined Transform Functions (UDTFs). A query containing a UDTF that takes many input columns (e.g. more than 1000) and also returns many columns may fail with error "Request size too big" due to additional memory requirement in parsing.

Workaround: Increase configuration parameter MaxParsedQuerySizeMB or reduce the number of output columns. For the cases of APPLY_SVD and APPLY_PCA, you can limit the number of output columns either by setting the parameter num_components or by setting the parameter cutoff. In practice, cutoff=0.9 is usually enough.

Please note that If you increase MaxParsedQuerySizeMB to a larger value, for example 4096, each query you run may use 4 GB of memory during parsing. This means that running multiple queries at the same time could cause out-of-memory (OOM) errors if your total memory is limited. Please refer to Vertica documentation for more information about MaxParsedQuerySizeMB.

Using a machine learning (ML) function, which accepts a model as a parameter, in the definition of a view, and then feeding that view into another ML function as its input relation may cause failure in some special cases.

Workaround: You should always prefix a model_name with its appropriate schema_name when you use it in the definition of a view.

If a configuration parameter in vertica.conf begins with the # character, Vertica crashes and throws an unhandled error. For example:

# LDAPLinkBindPswd = #A^F&pGt2J9S#

LDAPLinkFilterGroup = #cn=EDW*

# LDAPLinkFilterUser = cn=*

Workaround: Avoid using parameter values beginning with "#" in the vertica.conf file.

When creating an Eon Mode database through Management Console on an AWS cluster, entering a valid communal storage location and selecting IAM Role authentication does not enable the Next button. This issue occurs during database creation only, not when creating an Eon Mode database cluster.

Workaround: On the same wizard page, select “Use AWS Key Credentials”, enter enough text to enable the Next button, then select IAM Role authentication. Then click the Next button.

During cluster formation, when one of the up-to--date nodes are missing libraries and attempts to recover them, the recovery fails with a cluster shutdown.

Workaround: Copy libraries into the node's Libraries/ directory from a peer node.

In the Vertica Management Console (MC) in AWS, with some Vertica BYOL licenses, when using Cluster Management to add an instance to a Vertica database cluster, you are prompted to upload a license file even if your Premium Edition license is already installed. In the Add Instance wizard, the message 'Your database exceeds the free Community Edition limits, please upload a valid Premium Edition license.' appears.

Workaround: Upload your license file again and the instance and database node are added.