Re: Deadlock in libpq

On Thu, Mar 24, 2011 at 20:38, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> 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.

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).

Erik