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 outputs 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 running multiple queries at the same time could cause out-of-memory (OOM) if your total memory is limited. Please refer to Vertica documentation for more information about MaxParsedQuerySizeMB.

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

Workaround: Halt the remaining processes using admin tools.

Under special circumstances, a sequence of statements to create and drop Python libraries fails. For example, the following session statements attempt to create Python libraries lib1 and lib2:

CREATE LIBRARY lib1 AS :lib1_path DEPENDS :numpy_path LANGUAGE 'Python'; DROP LIBRARY lib1; CREATE LIBRARY lib2 AS :lib2_path DEPENDS :sklearn_path LANGUAGE 'Python';

Here, lib1 is a Python library that imports module numpy, while lib2 imports module sklearn, which relies on numpy. After lib1 is dropped, the CREATE LIBRARY statement for lib2 fails. Workaround: One of the following:

• In the same session, repeat the CREATE LIBRARY statement for the second library.
• Start another session and create the second library.
• Add the following lines of code to the second library's Python script before importing its module:

  import importlib
  importlib.reload(<library-1-module>)
  # e.g. importlib.reload(numpy)
  

A vbr restore operation can fail if your database is configured for SSL and has a server.key and a server.crt file present in the catalog directory.

Workaround: Move your SSL authentication related files (server.crt, server.csr and server.key) from the catalog directory before performing the restore.

Creating a load balance group for a subcluster with a ROUNDROBIN load balance policy only has an effect if you set the global load balancing policy to ROUNDROBIN as well. This is the case, even though the LOAD_BALANCE_GROUPS system table shows the group's policy as ROUNDROBIN.

Workaround: Set the global load balancing policy using the SET_LOAD_BALANCE_POLICY function: SELECT set_load_balance_policy('roundrobin');

When quickly stopping and then starting a different database, the new database may fail to start after attempting to connect to Spread processes associated with the stopped database.

Workaround: After stopping a database, ensure that all old Spread processes have stopped on the affected nodes before starting a different database. This typically takes no more than one minute, but may vary under certain circumstances.

Under special circumstances, a sequence of statements to create and drop Python libraries fails. For example, the following session statements attempt to create Python libraries lib1 and lib2:

CREATE LIBRARY lib1 AS :lib1_path DEPENDS :numpy_path LANGUAGE 'Python';
DROP LIBRARY lib1;
CREATE LIBRARY lib2 AS :lib2_path DEPENDS :sklearn_path LANGUAGE 'Python';

Here, lib1 is a Python library that imports module numpy, while lib2 imports module sklearn, which relies on numpy. After lib1 is dropped, the CREATE LIBRARY statement for lib2 fails.

Several Vertica partition management operations support a force-split option: copy_partitions_to_table, drop_partitions, move_partitions_to_table, and swap_partitions_between_tables. In all cases, if force-split is true, and the operation specifies a range of partition keys that span multiple containers or part of a single container, Vertica executes the operation in two steps:

1. Breaks open the ROS containers

2. Reorganizes/merges the ROS containers as per operation requirements

Occasionally, the Tuple Mover would attempt to merge the split ROS containers before step 2 was complete, and the operation would fail. This issue has been resolved: the two stages are now part of a single transaction. Until the transaction is complete, the Tuple Mover does not queue merge requests on the split containers.

Vertica was unable to optimize queries on v_internal tables, where equality predicates (with operator =) filtered on columns relname or nspname, in the following cases:

• The predicate specified expressions with embedded characters such as underscore (_) or percentage (%). For example:

  SELECT * FROM v_internal.vs_columns WHERE nspname = 'x_yz';
  

• The query contained multiple predicates separated by AND operators, and more than one predicate queried the same column, either nspname or relname. For example:

  SELECT * FROM v_internal.vs_columns WHERE nspname = 'xyz' AND nspname <> 'vs_internal'
  

In this case, Vertica was unable to optimize equality predicate nspname = 'xyz'.

In all these cases, the queries are now optimized as expected.

A ROS of inactive partitions was excluded from mergeout if it was very large in relation to the size of other ROS's to be merged. Now, a large ROS container of inactive partitions is merged with smaller ROS containers when the following conditions are true:

• Total number of ROS containers for the projection is close to the threshold for ROS pushback.
• Total mergeout size does not exceed the limit for ROS container size.

DROP_PARTITIONS requires that the range of partition keys to drop exclusively occupy the same ROS container. If the target ROS container contains partition keys that are outside the specified range of partition keys, the force-split argument must be set to true, otherwise the function returns with an error.

In rare cases, DROP_PARTITIONS executes at the same time as a mergeout operation on the same ROS container. When this happens, the function cannot execute the force-split operation and returns with an error. This error message has been modified to better identify the source of the problem, and also provides a hint to try calling DROP_PARTITIONS again.

Previously, export operations such as export_tables() exported all table constraints as ALTER statements, whether they were part of the original CREATE statement, or added later with ALTER TABLE. This was problematic for global temporary tables, which cannot be modified with any constraints other than foreign keys; attempts to add constraints on a temporary table with ALTER TABLE return with an error. Thus, the DDL that was exported for a temporary table with constraints could not be used to reproduce that table.

This problem has been resolved: now, export operations always export DDL for all constraints (except foreign keys) as part the CREATE statement. This change applies to all tables, temporary and otherwise.