The sqltypes_td.h header file redefines malloc to call FNC_malloc.
WHEN you … | THEN … |
---|---|
develop, test, and debug a UDF, UDM, or external stored procedure standalone | include the malloc.h header file and use the standard malloc and free C library functions. |
install the source code on the server | do not include malloc.h and use the definitions of malloc and free from the sqltypes_td.h header file. Note that the definitions are used when installing source code on the server, but not when installing objects. |
FNC_malloc and FNC_free check to make sure the UDF, UDM, table operator, contract function, or external stored procedure releases all memory before exiting and gives an exception on the transaction if the UDF, UDM, table operator, contract function, or external stored procedure does not release all temporary memory it allocated. This is to prevent memory leaks in the database.
A table function that calls FNC_malloc to allocate memory does not have to call FNC_free to release the memory until at least the TBL_END or TBL_ABORT phase. This means that the table function must use the FNC_TblAllocCtx and FNC_TblGetCtx calls to save the address that FNC_malloc returns in the general scratch pad.
The maximum amount of memory that any one external routine can allocate is a global configuration setting, where the default is 32MB.
To view or change the memory allocation limit, you can use the cufconfig utility. For example, to view the memory allocation limit, use the -o option of cufconfig and find the setting for the MallocLimit field:
cufconfig -o
For information on cufconfig and the MallocLimit field, see Teradata Vantage™ - Database Utilities, B035-1102.
This does not necessarily guarantee that an external routine can allocate the maximum amount of memory at all times. For performance reasons, an external routine should allocate as little memory as possible. Remember that UDFs and table operators execute in parallel on the database. An all-AMP query that includes a UDF or a table operator allocating 10MB for one instance can use up to 1GB for all instances on a 100 AMP system for just one transaction.
If you circumvent the logic to call malloc and free directly, then there is a good chance that memory leaks could occur even if the UDF, UDM, table operator, contract function, or external stored procedure frees up memory correctly. The reason is that a UDF, UDM, table operator, contract function, or external stored procedure can abort while it is running if a user aborts the transaction, or if the transaction aborts because of some constraint violation that might occur on another node unbeknownst to the running UDF, UDM, table operator, contract function, or external stored procedure.