When you connect to your database, vsql can show the following message:

{{Bad terminal type: "vt100". Will assume vt100.}}

This message can be safely ignored.

JDBC complex types return NULL arrays as empty arrays. For example, when executing this SQL statement:

SELECT ARRAY[null,ARRAY[1,2,3],null,ARRAY[4,5],null] as array;

The array column the server returns will be:

[[],[1,2,3],[],[4,5],[]]

Because of the null values in the string literal, it should return this value:

[null,[1,2,3],null,[4,5],null]

This is a work around to a limitation in Simba.

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.

The following improvements have been made to LDAPLink:

• LDAP synchronizations have been optimized and now are much faster for nested groups.
• Query profiling now works with LDAP dryrun functions.

The following improvements have been made to LDAPLink:

• LDAP synchronizations have been optimized and now are much faster for nested groups.
• Query profiling now works with LDAP dryrun functions.

Previously, the connection property FastCursorClose was set to {{false}} by default, which prevented you from canceling sqlfetch(); you had to set it to true with {{conn.addToConnString("FastCursorClose=1");}} to cancel requests.

FastCursorClose is now set to {{true}} by default.

Previously, when a cluster lost quorum and switched to read-only mode or stopped, some transaction commits in the queue might get processed. However, due to the loss of quorum, these commits might not have been persisted. These "transient transactions" were reported as successful, but they were lost when the cluster restarted.

Now, when Vertica detects a transient transaction, it issues a WARNING so you can diagnose the problem, and it creates an event in ACTIVE_EVENTS that describes what happened.

Previously, user-defined global resource pools could have the same name as subcluster resource pools. This is no longer supported. However, different subclusters can still have resource pools with the same name.

When you create a new subcluster resource pool, Vertica checks whether there is any global pool with the same external name, and vice versa. For example:

=> SELECT name, subcluster_name FROM RESOURCE_POOLS WHERE name = 'test_pool';

   name    |   subcluster_name

--------{-}{{-}}{{-}}+{{-}}{{-}}{-}-------------------

 test_pool | secondary_subcluster

(1 row)

=> CREATE RESOURCE POOL test_pool  maxmemorysize '2G';

ROLLBACK 4593:  Resource pool "test_pool" already exists