On Fri, Mar 25, 2011 at 3:26 AM, Erik Hesselink <hesselink@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
