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
- pthread_libpq.c (text/x-csrc)
- cryptohash-libpq-v2.patch (text/x-diff) patch v2
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
-
Set libcrypto callbacks for all connection threads in libpq
- 2c0cefcd1816 14.0 landed