Evan Czaplicki <evancz@xxxxxxxxx> writes: > I noticed that OpenSSL has a CRYPTO_set_mem_functions > <https://www.openssl.org/docs/man3.2/man3/CRYPTO_set_mem_functions.html> > function: >> If no allocations have been done, it is possible to “swap out” the default >> implementations for OPENSSL_malloc(), OPENSSL_realloc() and OPENSSL_free() >> and replace them with alternate versions. > But a different technique is used in contrib/pgcrypto/openssl.c >> To make sure we don't leak OpenSSL handles on abort, we keep OSSLCipher >> objects in a linked list, allocated in TopMemoryContext. We use the >> ResourceOwner mechanism to free them on abort. > Would it be desirable to do this? If not, why is the TopMemoryContext > approach a better option? I do not understand the code quite well enough to > evaluate the tradeoffs myself yet! Seems to me that these address different purposes. If we put in a CRYPTO_set_mem_functions layer, I doubt that we'd have any good idea of which allocations are used for what. So we could not replace what pgcrypto is doing with a simple MemoryContextReset (even if we cared to assume that freeing an OSSLCipher involves only free() operations and no other resources). I think the only real win we'd get from such a layer is that OpenSSL's allocations would be better exposed for accounting purposes, eg the pg_backend_memory_contexts view. That's not negligible, but I don't find it a compelling reason to do the work, either. regards, tom lane
