Fenced Mode

User-Defined Extensions (UDxs) written in the C++ programming language have the option of running in unfenced mode, which means running directly within the Vertica process. Since they run within Vertica, unfenced UDxs have little overhead, and can perform almost as fast as Vertica's own built-in functions. However, since they run within Vertica directly, any bugs in their code (memory leaks, for example) can destabilize the main Vertica process that can bring one or more database nodes down.

You can instead opt to run most C++ UDxs in fenced mode, which runs the UDxs code outside of the main Vertica process in a separate zygote process. UDx code that crashes while running in fenced mode does not impact the core Vertica process. There is a small performance impact when running UDx code in fenced mode. On average, using fenced mode adds about 10% more time to execution compared to unfenced mode.

Fenced mode is currently available for all C++ UDxs with the exception of User-Defined Aggregates. All UDxs developed in the Python, R, and Java programming languages must run in fenced mode, since the Python, R, and Java runtimes cannot be directly run within the Vertica process.

Using fenced mode does not affect the development of your UDx. Fenced mode is enabled by default for UDx's that support fenced mode. The CREATE FUNCTION command can optionally be issued with the NOT FENCED modifier to disable fenced mode for the function. Also, you can enable or disable fenced mode on any fenced mode-supported C++ UDx by using the ALTER FUNCTION command.

About the Zygote Process

The Vertica zygote process starts when Vertica starts. Each node has a single zygote process. Side processes are created "on demand". The zygote listens for requests and spawns a UDx side session that runs the UDx in fenced mode when a UDx is called by the user.

About Fenced Mode Logging:

UDx code that runs in fenced mode is logged in the UDxZygote.log and is stored in the UDxLogs directory in the catalog directory of Vertica. Log entries for the side process are denoted by the UDx language (for example, C++), node, and zygote process ID, and the UDxSideProcess ID.

For example, for the following processes...

    node_name     |   process_type   |            session_id            |  pid  | port  | status 
 v_vmart_node0001 | UDxZygoteProcess |                                  | 27468 | 51900 | UP
 v_vmart_node0001 | UDxSideProcess   | localhost.localdoma-27465:0x800b |  5677 | 44123 | UP

... the corresponding log file displays:

2016-05-16 11:24:43.990 [C++-localhost.localdoma-27465:0x800b-5677]  0x2b3ff17e7fd0 UDx side process started
 11:24:43.996 [C++-localhost.localdoma-27465:0x800b-5677]  0x2b3ff17e7fd0 Finished setting up signal handlers.
 11:24:43.996 [C++-localhost.localdoma-27465:0x800b-5677]  0x2b3ff17e7fd0 My port: 44123
 11:24:43.996 [C++-localhost.localdoma-27465:0x800b-5677]  0x2b3ff17e7fd0 My address:
 11:24:43.996 [C++-localhost.localdoma-27465:0x800b-5677]  0x2b3ff17e7fd0 Vertica port: 51900
 11:24:43.996 [C++-localhost.localdoma-27465:0x800b-5677]  0x2b3ff17e7fd0 Vertica address:
 11:25:19.749 [C++-localhost.localdoma-27465:0x800b-5677]  0x41837940 Setting memory resource limit to -1
 11:30:11.523 [C++-localhost.localdoma-27465:0x800b-5677]  0x41837940 Exiting UDx side process

The last line indicates that the side process was killed. In this case it was killed when the user session (vsql) closed.

About Fenced Mode Configuration Parameters

Fenced mode supports three configuration parameters:

See Also