From: Jacob Champion <pchampion@vmware.com>
To: michael@paquier.xyz <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: cryptohash: missing locking functions for OpenSSL <= 1.0.2?
Date: Mon, 8 Mar 2021 18:06:32 +0000
Message-ID: <8200dc155937c1a7e5d9ea19cc65d95e89d0bc4d.camel@vmware.com> (raw)
In-Reply-To: <YD8s+dMvc4GH1Ymu@paquier.xyz>
References: <fd3ba610085f1ff54623478cf2f7adf5af193cbb.camel@vmware.com>
<YC3LFcb5/k2o89Ho@paquier.xyz>
<YC9Ogi7Xl6KdjE7D@paquier.xyz>
<YD8s+dMvc4GH1Ymu@paquier.xyz>
On Wed, 2021-03-03 at 15:30 +0900, Michael Paquier wrote:
> Extra eyes are welcome here, though I feel comfortable with the
> approach taken here.
I have one suggestion for the new logic:
> else
> {
> /*
> * In the non-SSL case, just remove the crypto callbacks. This code
> * path has no dependency on any pending SSL calls.
> */
> destroy_needed = true;
> }
> [...]
> if (destroy_needed && conn->crypto_loaded)
> {
> destroy_ssl_system();
> conn->crypto_loaded = false;
> }
I had to convince myself that this logic is correct -- we set
destroy_needed even if crypto is not enabled, but then check later to
make sure that crypto_loaded is true before doing anything. What would
you think about moving the conn->crypto_loaded check to the else
branch, so that destroy_needed is only set if we actually need it?
Either way, the patch looks good to me and behaves nicely in testing.
Thanks!
--Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pchampion@vmware.com, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org
Subject: Re: cryptohash: missing locking functions for OpenSSL <= 1.0.2?
In-Reply-To: <8200dc155937c1a7e5d9ea19cc65d95e89d0bc4d.camel@vmware.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox