Resolved issues

The Windows DSN configuration utility no longer sets vertica as the default KerberosServiceName value when editing a DSN.

Starting with version 11.1, providing a value causes the ODBC driver to assume the connection is using Kerberos authentication and communicates to the server that it prefers to use that authentication method, assuming that the user has a grant to a Kerberos authentication method. The KerberosServiceName value might be set in earlier versions of Windows ODBC DSNs. Clearing the value will resolve the issue. This issue only applies to users who have a Kerberos authentication method granted with a lower priority than other authentication methods and use the DSN configuration utility to set up a DSN on Windows.

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