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 <https://github.com/postgres/postgres/blob/REL_16_STABLE/contrib/pgcrypto/openssl.c#L52-L56> to work around the different allocation system of OpenSSL: 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. I see the particulars might have changed on the master branch though! CRYPTO_set_mem_functions must be called *before* any uses of malloc/free though, so I believe it needs to be called right after the OPENSSL_init_ssl <https://www.openssl.org/docs/man3.2/man3/OPENSSL_init_ssl.html> calls (e.g. in src/backend/libpq/be-secure-openssl.c <https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/libpq/be-secure-openssl.c#L102> and src/interfaces/libpq/fe-secure-openssl.c <https://github.com/postgres/postgres/blob/REL_16_STABLE/src/interfaces/libpq/fe-secure-openssl.c#L858>) for this to be possible. 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! Best, Evan P.S. Searcthing all time with this query <https://www.postgresql.org/search/?m=1&q=CRYPTO_set_mem_functions&l=&d=-1&s=r>, I found one thread in 2018 that mentions CRYPTO_set_mem_functions, but in a different capacity. I hope I did not miss some other mention of it on the email lists!
