On Tue, Nov 21, 2023 at 12:14:16PM +0300, Aleksander Alekseev wrote: Thanks for the report, Willi, and the test case! Thanks Aleksander for the reply.
> I wonder if we should just document that libpq is thread safe as of PG > v??? and deprecate PQisthreadsafe() at some point. Currently the > documentation gives an impression that the library may or may not be > thread safe depending on the circumstances. Because --disable-thread-safe has been removed recently in 68a4b58eca03. The routine could be marked as deprecated on top of saying that it always returns 1 for 17~. > Please add the patch to the nearest open commit fest [2]. The patch > will be automatically picked up by cfbot [3] and tested on different > platforms. Also this way it will not be lost among other patches. > > The code looks OK but I would appreciate a second opinion from cfbot. > Also maybe a few comments before my_BIO_methods_init_mutex and/or > pthread_mutex_lock would be appropriate. Personally I am inclined to > think that the automatic test in this particular case is redundant. I am not really convinced that we require a second mutex here, as there is always a concern with inter-locking changes. I may be missing something, of course, but BIO_s_socket() is just a pointer to a set of callbacks hidden in bss_sock.c with BIO_meth_new() and BIO_get_new_index() assigning some centralized data to handle the methods in a controlled way in OpenSSL. We only case about initializing once for the sake of libpq's threads, so wouldn't it be better to move my_BIO_s_socket() in pgtls_init() where the initialization of the BIO methods would be protected by ssl_config_mutex? That's basically what Willi means in his first message, no? -- Michael
signature.asc
Description: PGP signature
