Resolved issues

Enhanced Vertica Database Initialization for Custom Setups: Previously, coordinating initial setup tasks for Vertica databases on Kubernetes pods, such as creating users, schemas, or installing UDX libraries, was challenging. Users often resorted to complex workarounds to ensure these configurations ran only after the database was fully initialized.

Solution: We have introduced a new capability that allows you to define a custom job specification within VerticaDB. This job will automatically execute a user-defined container once the Vertica database has been successfully initialized.

Benefits: This enhancement simplifies and automates the process of performing critical post-initialization setups. Customers can now seamlessly integrate custom configurations, run Ansible scripts, or deploy C++ UDX libraries, ensuring their Vertica environment is ready for use without manual intervention or complex coordination logic.

ODBC-Loader: PCRE Library Compatibility on Amazon Linux and RHEL 8.x: The ODBC-Loader previously encountered compatibility issues on Amazon Linux and Red Hat Enterprise Linux 8.x environments. This was due to a dependency on a specific build of the PCRE (Perl Compatible Regular Expressions) library, which led to runtime errors (missing symbols from libpcrecpp) when standard system-provided PCRE packages were utilized.

Resolution/Workaround: To ensure the correct functionality of the ODBC-Loader in these specific environments, a manual procedure is required. Users must perform the following steps:

1. Remove any existing pcre-devel and pcre-cpp packages.
2. Manually download and compile PCRE version 8.45 from its source, ensuring the use of specific compiler flags (CXXFLAGS='-std=c++11 -D_GLIBCXX_USE_CXX11_ABI=0').
3. Update the system's dynamic linker configuration to recognize the newly installed PCRE libraries.
4. Recompile the ODBC-Loader itself, applying the same specified CXXFLAGS used during the PCRE compilation. This detailed procedure ensures that the ODBC-Loader correctly links against a compatible PCRE build, thereby resolving the previously observed runtime issues.

Query Performance Degradation with Views Containing Null Columns: Fixed an issue where queries utilizing views that included additional null columns could lead to unexpected changes in the query execution plan. This often resulted in significantly higher memory consumption and 'join inner did not fit into the memory' errors, particularly impacting some standard queries.

This fix ensures more stable and optimized query execution, preventing out-of-memory issues and improving the reliability and performance of queries involving such views.

This fix addresses the root cause allowing non-UTF-8 data and oversized byte strings to be stored in VARCHAR columns. The system now correctly enforces VARCHAR length constraints and ensures proper UTF-8 character handling during data insertion and processing, especially within recursive CTEs and temporary relation reuse mechanisms. This prevents the storage of invalid data and eliminates the associated query failures.

Workarounds (Prior to Fix):

Before the implementation of this fix, customers could mitigate the issue by:

1. Disabling the EnableWITHTempRelReuseLimit session parameter.
2. Enabling the WithClauseMaterialization session parameter. However, this option was noted to cause significant performance degradation, particularly with higher WithClauseRecursionLimit values.

Excessive vertica.log Growth Leading to Node Failures: Previously, an issue was identified where vertica.log files would grow excessively large, sometimes by over 20GB in 30 minutes, due to frequent logging of [EE] <INFO> arg1, arg2, res: messages. This uncontrolled log growth consumed all available disk space in the catalog directory, leading to node failures and impacting subcluster availability.

Resolution: This fix addresses the root cause of the excessive logging. The system has been updated to prevent the frequent generation of [EE] <INFO> arg1, arg2, res: messages at an INFO level, thereby controlling the size of vertica.log files.

Impact: This resolution prevents future node failures caused by disk space exhaustion due to log growth, ensuring greater system stability and availability for Eon mode deployments running Vertica v24.3.0-1 and later.

Vertica Eon Mode - Corrected TEMP Data Location for Newly Added Nodes: Previously, in Vertica Eon mode clusters, when new nodes were added following a database revive operation, the DATA,TEMP storage locations on these newly provisioned nodes were incorrectly configured to point to the catalog path (e.g., /vertica_catalog) instead of the intended data path (e.g., /vertica_tmp or the specified data directory). This behavior deviated from the standard configuration observed on original nodes or nodes added to a freshly created database.

Resolution: This issue has been resolved. With this fix, all newly added nodes to an Eon mode cluster, even after a database revive, will now correctly configure their DATA,TEMP storage locations to the designated data paths, ensuring consistent and proper storage management across the cluster.

This fix addresses "Insufficient resources to execute plan on pool general" errors, specifically memory exhaustion, causing transactions to fail. This issue affected queries that previously ran without problems on Vertica 10.1v, even after increasing node RAM from 500GB to 600GB. This could lead to operational disruptions and resource allocation problems within the Vertica cluster.

Resolution: This fix resolves the memory resource allocation inefficiencies and errors, enabling successful query execution within configured resource limits.

Catalog Truncation for Compressed Transaction Logs Issue: Previously, when catalog truncation was performed on compressed transaction log files, an incorrect counter was used to determine the log size. This led to the transaction log file being truncated more than necessary, resulting in corruption and subsequent startup failures.

Resolution: The system now correctly identifies and uses the appropriate counter to determine the size of compressed transaction log files during truncation. This ensures that the last transaction file is truncated accurately, preventing corruption and ensuring successful restarts.

Fix for FAILED_LOGIN_ATTEMPTS Profile Parameter: Previously, the FAILED_LOGIN_ATTEMPTS profile parameter in Vertica did not function as expected. When a user profile was configured with a specific limit for failed login attempts (e.g., 5 attempts), the user account would unexpectedly lock after a fewer number of failed attempts (e.g., 3 attempts). This discrepancy led to premature account lockouts, causing inconvenience for end-users and impacting business operations. This behavior was specifically observed and reproduced in Vertica Analytic Database v25.1.0-0.

Resolution: This issue has been resolved. The FAILED_LOGIN_ATTEMPTS profile parameter now correctly enforces the configured number of failed login attempts before locking a user account. Users will no longer experience premature account lockouts due to this parameter, ensuring that security policies are applied as intended.

--ssh-password Option Failure in install_vertica and update_vertica: Previously, the --ssh-password option in the install_vertica and update_vertica scripts was not being correctly applied. This led to the scripts prompting for an SSH password and becoming unresponsive during installation or upgrade processes, especially in environments where passwordless SSH was not configured. This behavior resulted in incomplete upgrades and operational disruptions.

Resolution: The --ssh-password option is now properly recognized. The install_vertica and update_vertica scripts now correctly utilize the provided SSH password, ensuring smooth and uninterrupted execution without unexpected password prompts.

S3 Streaming Connection Management Improvement: Previously, the S3 layer could improperly count streaming connections, potentially leading to connection pool exhaustion during surges of S3 requests. This issue could block S3 reads, including critical operations like TxnLogSync, and impact query performance.

This release includes an improvement to ensure streaming connections are counted atomically and managed correctly, preventing connection pool exhaustion and ensuring reliable S3 read operations, even under high load.

Security Fix: Golang Vulnerabilities in Vertica Binaries: This release addresses multiple security vulnerabilities found in Golang binaries shipped with Vertica 26.1.0-0. These vulnerabilities, including several critical and high-severity CVEs, affected core Vertica components and could prevent deployment in Kubernetes environments with strict vulnerability-based admission controllers.

Key Vulnerabilities Addressed:

• CVE-2024-45337 (CRITICAL): Authorization bypass in golang.org/x/crypto/ssh.
• CVE-2025-68121 (CRITICAL/UNKNOWN): Session resumption issue in crypto/tls.
• CVE-2025-22869 (HIGH): Denial of Service in golang.org/x/crypto/ssh.
• CVE-2025-61726 (HIGH): Memory exhaustion in net/url query parameter parsing. Resolution: The fix involves updating vulnerable Golang dependencies, specifically golang.org/x/crypto to v0.45.0, golang.org/x/net to v0.47.0, and github.com/go-viper/mapstructure/v2 to v2.4.0. Additionally, the Go compiler has been upgraded to version 1.24.13 to resolve stdlib vulnerabilities. This update significantly enhances the security posture of Vertica container images.

Affected Components:

• opt/vertica/bin/vcluster
• opt/vertica/bin/vcluster_server
• opt/vertica/bin/vertica-client-proxy
• opt/vertica/bin/vertica_mcp_server
• opt/vertica/bin/node_management_agent

Before the fix, the Kubernetes operator may error out upon seeing remote user storage location when reviving an Eon database migrated from 10.x Enterprise database.

With the fix, the Kubernetes operator correctly handles the remote user storage locations created in old version enterprise database for reviving.

Performance Improvement for Snapshot Loading: This release addresses a performance bottleneck observed during the load_snapshot() operation, which could sometimes take up to 4 hours on certain nodes.

Key Improvements:

• Optimized Storage Container Checks: Reduced redundant checks for storage locations within Storage Containers (SCs).
• Streamlined CRC Verification: Introduced optimizations to skip unnecessary CRC checks for existing storage bundles. These enhancements significantly improve the efficiency and reduce the duration of the load_snapshot() process, leading to faster system recovery and improved overall performance.

View Creation with UNNEST and CASE Expressions: Previously, users encountered an ERROR 3457: Function unnest(-) does not exist when attempting to create a view that utilized the unnest function within a CASE expression. This specific issue manifested when the CASE expression involved NULL arrays of complex types, such as ARRAY[ROW(...)] or ARRAY[ARRAY[...]].

Resolution: This release includes a fix that resolves the type resolution issue for unnest functions within CASE expressions during view creation. Users can now successfully define views containing unnest with CASE expressions, even when handling NULL arrays of complex types, without encountering the aforementioned error.

Security Update: verticadb-operator: This release includes an important security fix for verticadb-operator:26.1.2-0.

Resolved Issue:

• CVE-2026-33186: Addressed a critical security vulnerability in the gRPC component, which required an upgrade to a patched version. This update enhances the security posture of the operator.

Scrutinize System Tables Collection on Kubernetes: This release addresses an issue where running Scrutinize using a Custom Resource Definition (CRD) on Kubernetes, specifically in prod and dev EON environments, failed to collect system tables. Previously, the generated Scrutinize tarball did not include these critical system tables, impacting diagnostic capabilities.

With this fix, Scrutinize tarballs generated via CRD on Kubernetes will now correctly include all expected system tables, ensuring comprehensive data collection for troubleshooting and analysis.

Vertica 26.x Client Driver SSL Connectivity Fix Issue Addressed: This release resolves a critical defect affecting Vertica 26.1.0-3 client drivers (ODBC and vsql). Previously, these drivers failed to establish connections to Vertica servers with SSL enabled. Users experienced issues such as the ODBC test connection screen disappearing without a message and vsql exiting without an error, blocking customer operations. This behavior was specific to Vertica 26.x drivers, while Vertica 25.x drivers functioned correctly under the same conditions.

Resolution: This fix ensures that Vertica 26.x client drivers now correctly connect to SSL-enabled Vertica servers, restoring stable and secure connectivity and aligning with the expected behavior observed in previous driver versions.