Re: Deadlock in libpq

On Thu, Mar 24, 2011 at 11:57 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Thu, Mar 24, 2011 at 11:52 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> As far as connections getting dropped: yes, this sounds reasonable,
>>> but given that both the client and the server are running on the same
>>> machine, will connections (to 127.0.0.1) really be dropped once every
>>> 100.000 or so?
>>
>> No, don't bother, I forgot the default behavior was to do both, which
>> is probably correct in your case. InitSSL just signals if you want
>> them to be done.
>>
>> libpq refcounts connections and does SSL initialization when
>> connection count goes from 0->1 and destruction when it goes from
>> 1->0.  This operation is protected with mutex (you *are* using thread
>> safe libpq, right?).
>
> meh, you have to be -- the locking stuff only gets set up w/thread
> safe libpq.  It's basically impossible for that refcount to get thrown
> off aiui.  hm.  I'm going back to thinking tom was right and this is
> threading issue in the app...maybe there is something you haven't
> considered?

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.

merlin