Re: BUG #16160: Minor memory leak in case of starting postgres server with SSL encryption

I'm pretty sure it was the only cause in this specific case. When running
postgres with valgrind this was the only block that was repeatedly being
leaked.

Originally we also thought that root_cert_list could be the cause. Changing
the size of the root cert did not speed up the memory leak though, so this
was rejected as one of the causes (before we ran postgres with valgrind).
The reason it doesn't leak is that root_cert_list gets added to the SSL_CTX
a little while after creation if everything goes well.

Looking at it again now, I see that if an error occurs when parsing
ssl_crl_file the root_cert_list is in fact leaked. This was easy to
reproduce by specifying a bogus path for ssl_crl_file. Running postgres
again with valgrind then yields this leak (when stopping it after 47
SIGHUPs):

==13061== 30,738 (1,504 direct, 29,234 indirect) bytes in 47 blocks are
definitely lost in loss record 147 of 148
==13061== at 0x4C31B0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13061== by 0x5825F08: CRYPTO_zalloc (build_shared/../crypto/mem.c:230)
==13061== by 0x588702E: OPENSSL_sk_new_reserve
(build_shared/../crypto/stack/stack.c:209)
==13061== by 0x544D644: sk_X509_NAME_new_null
(build_shared/../include/openssl/x509.h:77)
==13061== by 0x544D644: SSL_load_client_CA_file
(build_shared/../ssl/ssl_cert.c:634)
==13061== by 0x3F814D: be_tls_init
(home/jelte/.pgenv/src/postgresql-11.10/src/backend/libpq/be-secure-openssl.c:221)
==13061== by 0x3E65F0: secure_initialize
(home/jelte/.pgenv/src/postgresql-11.10/src/backend/libpq/be-secure.c:77)
==13061== by 0x4973C5: SIGHUP_handler
(home/jelte/.pgenv/src/postgresql-11.10/src/backend/postmaster/postmaster.c:2603)
==13061== by 0x4E5097F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so)
==13061== by 0x6C8FDD6: select
(build/glibc-S9d2JN/glibc-2.27/misc/../sysdeps/unix/sysv/linux/select.c:41)
==13061== by 0x49B50E: ServerLoop
(home/jelte/.pgenv/src/postgresql-11.10/src/backend/postmaster/postmaster.c:1692)
==13061== by 0x49C9F7: PostmasterMain
(home/jelte/.pgenv/src/postgresql-11.10/src/backend/postmaster/postmaster.c:1401)
==13061== by 0x3F947A: main
(home/jelte/.pgenv/src/postgresql-11.10/src/backend/main/main.c:228)

Parsing our ssl_crl_file did not cause errors though, so in our case this
was not the cause.