Evan Czaplicki <evancz@gmail.com> 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