On 2/12/15 7:28 AM, Jan Urbański wrote: >>>>> * If there's already callbacks set: Remember that fact and don't >>>>> overwrite. In the next major version: warn. >>>> >>>> So yeah, that was my initial approach - check if callbacks are set, don't >>>> do >>>> the dance if they are. It felt like a crutch, though, and racy at that. >>>> There's >>>> no atomic way to test-and-set those callbacks. The window for racyness is >>>> small, though. >>> >>> If you do that check during library initialization instead of every >>> connection it shouldn't be racy - if that part is run in a multithreaded >>> fashion you're doing something crazy. >> >> Yes, that's true. The problem is that there's no real libpq initialisation >> function. The docs say that: >> >> "If your application initializes libssl and/or libcrypto libraries and libpq >> is >> built with SSL support, you should call PQinitOpenSSL" >> >> So most apps will just not bother. The moment you know you'll need SSL is >> only >> when you get an 'S' message from the server... > > For the sake of discussion, here's a patch to prevent stomping on > previously-set callbacks, racy as it looks. > > FWIW, it does fix the Python deadlock and doesn't cause the PHP segfault...
I don't think this patch would actually fix the problem that was described after the original bug report (http://www.postgresql.org/message-id/5436991b.5020...@vmware.com), namely that another thread acquires a lock while the libpq callbacks are set and then cannot release the lock if libpq has been shut down in the meantime. The only way to fix that is to never unset the callbacks. But we don't want that or can't do that for other reasons. I think the only way out is to declare that if there are multiple threads and other threads might be using OpenSSL not through libpq, then the callbacks need to be managed outside of libpq. In environments like PHP or Python this would require some coordination work across modules somehow, but I don't see a way around that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
