Rocket® Vertica

Location of TEMP data for nodes that were added to the cluster are not default. Environment Vertica Analytics Database v25.1 Situation User added 16 nodes to an 8 node cluster (added nodes and successfully resharded). New nodes that were added the 'DATA,TEMP' location is pointing to /vertica_catalog and not /vertica_tmp like the original nodes. The user usually uses the --data_path flag to point the 'DATA,TEMP' locations to /vertica_tmp when creating the database, but according to vertica admintools documentation the db_add_node tool doesn't see to have that flag and the user assumes that if there's no flag it would use the same value as the other nodes in the cluster they're being added to. Issue occurs only when the database is revived and then nodes are added. If nodes are added without performing a revive, the problem does not appear. Find complete article on support portal

General pool to have less than 25% of system memory available Environment Vertica Analytics Database v11.0.1 Situation The following error was being experienced by the user: WARNING:2026-01-08 03:07:12.000 MetadataPoolMonitor:0x7ff118ffd700 <WARNING> @v_db_node0001: 01000/7795: Vertica metadata size, which includes the database catalog, is too large, and has caused the general pool to have less than 25% of system memory available Find complete article on support portal

An INSERT may run much longer than expected and appear to request an extremely large memory budget. Investigation shows the large “reported” memory requirement is driven by resource pool policy/configuration (runtime caps and pool routing), not actual memory usage. When the query exceeds the configured runtime cap, Vertica can move it from a short-running pool to a long-running pool, which changes how it is managed and can contribute to the observed slowdown. Environment Vertica Analytics database 24.3.x Situation INSERT takes much longer than baseline (minutes → hours). Monitoring/plan output shows a very large reported memory requirement or budget. Query is moved/reclassified due to runtime cap exceeded. Actual memory usage is significantly lower than the reported budget. Find complete article on support portal

This article provides information on how to enable STOP_ON_ERROR in the Vertica database. Environment Vertica analytics Database: v12.x Situation The SP_OPX_STOP_ON_DDL_ERR parameter which works for Version 11.3 looks like is not included in Version 12. So how do we control whether the Post process stops when a Data Definition Language (DDL) operation fails on a target database? Find resolution on support portal

Vertica Patch Notice26.1.0-x HOT-FIX The latest 26.1.0 patch has been released:*26.1.0-1 Release Notes: https://docs.vertica.com/release-notes/26.1.x/resolved-issues/ Vertica Patches available on the SLD Site: https://sld.microfocus.com/mysoftware/index If you need assistance, please contact Vertica Technical support via the customer portal at https://portal.microfocus.com/.

   Hi everyone, I am struggling to import the Google Universal Sentence Encoder (Multilingual) model into Vertica 25.4.1 using the TensorFlow integration. My Environment: OS: Rocky Linux 9 Vertica Version: 25.4.1-x TensorFlow: 2.15.0 TensorFlow Text: 2.15.0 (required for the multilingual USE ops) Python: 3.10 (for model freezing) The Issue: I have successfully loaded the USE model in Python, registered the SentencepieceOp via tensorflow_text, and exported it as a frozen .pb file with a corresponding tf_model_desc.json. However, when I run the following SQL command in Vertica: SELECT IMPORT_MODELS('/home/dbadmin/frozen_dir/' USING PARAMETERS category='TENSORFLOW'); I consistently get this error: ERROR 9450: Failed to import model(s): Failed to import single model: Error in importModelFiles: Error calling setup() in User Function import_model_files at [src/Common/TFCommon.cpp:51], error code: 0, message: Unsupported tensorflow type: 0 My tf_model_desc.json: { "frozen_graph

Vertica Version: 25.4.1 Category: SDK / Python UDx Function Type: ScalarFunction Description There is a critical inconsistency in the addLongVarchar() method signature within the Python SDK for ScalarFunctionFactory. The method behaves differently depending on whether it is called inside getPrototype() or getReturnType(), leading to TypeError in both scenarios if one tries to standardize the code. Steps to Reproduce In a standard ScalarFunctionFactory implementation: Scenario A: Passing a length argument def getPrototype(self, server_interface, arg_types, return_type): arg_types.addVarchar() return_type.addLongVarchar(32000) # Throws TypeError Result: TypeError: addLongVarchar() takes exactly 0 positional arguments (1 given) Scenario B: Passing no arguments def getReturnType(self, server_interface, arg_types, return_type): return_type.addLongVarchar() # Throws TypeError Result: TypeError: addLongVarchar() takes at least 1 positional argument (0 given) Observed Beh

"<WARNING> Could not estimate database size. Switching to exhaustive mode"?" Environment Vertica Analytics Database v24.4.0 Situation User is receiving more than 3000+ warning messages in 1 node cluster: "<WARNING> Could not estimate database size. Switching to exhaustive mode"?"<WARNING> Sampling excessively. Sample size is [10000]. Total cells [282]" In the logs we were able to find: 2026-02-20 08:00:43.495 Init Session:0x890ddffff6c0-a000000589c325 [Txn] <INFO> Begin Txn: a000000589c325 'executing audit'2026-02-20 08:00:43.496 Init Session:0x890ddffff6c0-a000000589c325 [EE] <WARNING> Sampling excessively. Sample size is [10000]. Total cells [51105]2026-02-20 08:00:43.496 Init Session:0x890ddffff6c0-a000000589c325 [EE] <WARNING> Could not estimate database size. Switching to exhaustive mode Based on the log entries, these warnings are generated by Vertica’s internal audit size-estimation process, which is invoked during query planning and m

After fixing root filesystem corruption on a Vertica node, the node still failed to start. The issue was resolved by restoring the Vertica installation directory (/opt/vertica) from a healthy node and reinstalling the Vertica RPM. After performing these steps, the node successfully rejoined the cluster. Environment Vertica Analytics Platform Multi-node cluster : Enterprise  Component: Vertica installation directory (/opt/vertica) Issue: Node unable to start after filesystem corruption repair Situation Node3 experienced root filesystem corruption, which was repaired at the OS level.However, even after correcting the filesystem, the Vertica node continued to fail during startup. This indicated that some Vertica installation files were missing, damaged, or inconsistent due to the previous corruption. Find complete article on support portal

Cannot enable tm services as the database keeps saying it is in READ ONLY mode Environment Vertica Analytics Database: version 12.x Situation The database fails to make any changes to its configuration on database level. Any attempt to make a change to configuration parameters results in below error - ROLLBACK: Cannot issue this command in a read-only transaction Find resolution on support portal

Hello. Do I need to re-register on the new forum, or is there a way to transfer my profile?

This knowledge article provides the Japanese Installation Guide for OpenText Analytics Database (Vertica) trial environment in 26.1. Environment OpenText Analytics Database (Vertica) 26.1 Situation OpenText Analytics Database (Vertica) 26.1を使用した評価環境構築手順。 Find resolution on support portal

This article describes the purpose and behavior of the 'Cluster Status Request' FATAL log messages that may appear in the vertica.log file. Environment OpenText Analytics Database (Vertica) Management Console (MC) Situation The following message was observed periodically in the vertica.log file:   Init Session:0x7fec52ffd700 <FATAL> @v_vmartdb_node0001: {SessionRun} 57V03/5785: Cluster Status Request by 172.16.0.15:42946HINT: Cluster State: VMartDBUP: 3 of 3 (v_vmartdb_node0001, v_vmartdb_node0002, v_vmartdb_node0003)----LOCATION: initSession, /data/qb_workspaces/jenkins2/ReleaseBuilds/Hammermill/REL-10_0_0-x_hammermill/build/vertica/Session/ClientSession.cpp:542   Find complete article on support portal

Did you know that OpenText helps people around the world stay stylish? GUESS?, Inc., headquartered in Los Angeles, California, is an internationally recognized fashion brand with over 1,500 retail locations across 92 countries as well as an online presence. With so many locations, employees, and supply line elements, Guess? Relies on OpenText™ Analytics Database for insights that speed app development, drive better business decisions, and boost operational efficiency. Read the full story

Environment Vertica Analytics Database version: 24.2 Situation After the installation of CrowdStrike, it was observed that the last data ingestion from the servers occurred around 16:30. When reviewing the microbatch execution history, the last batch runs were recorded between 16:40–16:50. Cause Antivirus CrowdStrike  Find resolution on support portal

Environment Vertica Analytics Database v23.4 Situation User has a 45 + 1 standby Vertica cluster where one specific node shows an offset in the CPU measurements: the node is 1 to 10 standard deviations higher than the other nodes, throughout the day. Find resolution on support portal

The backup failure is caused by instability on the NFS server, not by Vertica opening too many files or having “too many files” in the backup set. Multiple database nodes report the kernel message “NFS: server error: fileid changed”, which indicates that the NFS server is modifying file handles during the backup process. This interrupts file access and causes Vertica to fail with I/O errors. Environment Product: Vertica Analytics Platform Backup method: VBR backup to NFS-mounted directory Storage: NFS export OS indicators: Kernel/dmesg messages showing “fileid changed” Situation During a Vertica backup, the following kernel messages repeatedly appear on multiple database nodes (dmesg) Find complete article on support portal

Environment Vertica Analytics Database v25.4.0 Situation User had a few questions regarding migrating from enterprise to eon. Find resolution on support portal

Environment Vertica Analytic Database v12.0.3-3 Situation Vulnerability: 148367 (5444/6) – Python Unsupported Version Detection Find complete article on support portal

You can run the MCP server outside of Kubernetes and connect it to a Vertica database that is running inside Kubernetes. This setup allows you to execute SQL queries through the MCP server today. However, if your goal is to deploy the MCP server inside Kubernetes and use it to perform database operations (such as adding a subcluster), full in‑cluster MCP functionality will be available starting with the Vertica 26.3 release. Environment Product: Vertica Analytics Platform Feature: Management Command Protocol (MCP) Deployment Model: VerticaDB running on Kubernetes MCP server: External (today) or in‑cluster (26.3+) Situation A customer wants to use the MCP server with VerticaDB running in Kubernetes.Two scenarios were evaluated: Running MCP outside Kubernetes → Works today MCP server can connect to a VerticaDB running on Kubernetes. SQL queries and standard MCP functions work. Running MCP inside Kubernetes → Requires Vertica 26.3 Database operations like adding a subcluster 

This article provides information on why the vsql is failing while sending the client certificate. Environment: Vertica Analytics Database: v25.x or later Situation: The user expect the vsql client to send the client certificate to connect but its failing with below error on the logs. Could not accept TLS connection (3): error code: , location SSL routines:tls_process_client_certificate ssl /statem/statem_srvr.c:3509, reason [peer did not return a certificate] Find resolution on support portal

Products Analytics Database, Vertica Analytics Platform Vertica Clients Notice 26.1.0 Clients are now available for download. Release Notes: https://docs.vertica.com/release-notes/26.1.x/resolved-issues/ Vertica Clients available on the SLD Site: https://sld.microfocus.com/mysoftware/index If you need assistance, please contact Vertica Technical support via the customer portal at https://portal.microfocus.com/.

This article provides information on why the TLS config command failed and how to resolve it. Environment: Vertica Analytics Database: v24.3.x Situation: Not able to grant usage on certificate to the user. Below is the error, GRANT USAGE ON CERTIFICATE <certificate_name> TO <user_name>; ERROR 4856: Syntax error at or near "<certificate_name>" at character 28Find resolution on support portal