Re: cryptohash: missing locking functions for OpenSSL <= 1.0.2?

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Jacob Champion <pchampion@vmware.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-03T06:30:17Z
Lists: pgsql-hackers

Attachments

On Fri, Feb 19, 2021 at 02:37:06PM +0900, Michael Paquier wrote:
> The attached patch implements things this way, and initializes the
> crypto callbacks before sending the startup packet, before deciding if
> SSL needs to be requested or not.  I have played with several
> threading scenarios with this patch, with and without OpenSSL, and the
> numbers match in terms of callback loading and unloading (the global
> counter used in fe-secure-openssl.c gets to zero). 

I have done more work and much more tests with this patch, polishing
things as of the attached v2.  First, I don't see any performance
impact or concurrency issues, using up to 200 threads with pgbench -C
-n -j N -c N -f blah.sql where the SQL file includes a single
meta-command like that for instance:
\set a 1

This ensures that connection requests happen a maximum in concurrency,
and libpq stays close to the maximum for the number of open threads.
Attached is a second, simple program that I have used to stress the
case of threads using both SSL and non-SSL connections in parallel to
check for the consistency of the callbacks and their release, mainly
across MD5 and SCRAM.

Extra eyes are welcome here, though I feel comfortable with the
approach taken here.
--
Michael

Commits

  1. Set libcrypto callbacks for all connection threads in libpq