The sqltypes_td.h header file redefines malloc to call FNC_malloc.
| Activity | What to Do |
|---|---|
| Developing, testing, and debugging a UDF, UDM, or external stored procedure standalone | Include the malloc.h header file and use the standard malloc and free C library functions. |
| Installing 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. 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 allocated memory. 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
See Teradata Vantage™ - Database Utilities, B035-1102.
This does not guarantee that an external routine can always allocate the maximum amount of memory. For performance reasons, an external routine must allocate as little memory as possible. UDFs and table operators run 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, memory leaks may occur even if the UDF, UDM, table operator, contract function, or external stored procedure frees memory correctly. The reason is that a UDF, UDM, table operator, contract function, or external stored procedure can stop while running if a user stops the transaction, or if the transaction stops because of a constraint violation that may occur on another node.