Re: Deadlock in libpq

On Fri, Mar 25, 2011 at 3:26 AM, Erik Hesselink <hesselink(at)gmail(dot)com> wrote:
>> hm, ISTM (I don't know haskell) that the hdbc driver isn't doing any
>> type of synchronization at all unless it is using a non thread safe
>> libpq...and in that case it uses a global mutex.  That doesn't look
>> correct -- the hdbc driver should be locking around the PGconn always,
>> and globally if you're stuck with a non thread safe libpq.
>
> No, that is not the case. If libpq is not thread safe, the library
> uses a global lock. If it is thread safe, it uses a single lock per
> connection. This lock is created on connect, and locked before
> executing a statement. So it seems the library is doing the correct
> things.
>
> (And yes, libpq is thread safe, I just checked).

hm, I'm stumped. Are you sure nothing else is using the crypto
library? There is an unlikely but possible case that you initialized
crypto locks over somebody else.

*something* is happening here, but I have no idea what. I'm very
skeptical it's a locking issue in libpq itself, because there is so
little going on beyond counting the connections. Let me ask you this:
how much does your connection count range over time? would it be
possible to reserve a connection that stays open all the time and see
if the issue re-occurs? (a wild stab in the dark, but I'm curious of
ssl re-initialization is causing your problem if you always have at
least one connection open, it wont re-initialize).

merlin