Re: Deadlock in libpq - Mailing list pgsql-general

From Merlin Moncure
Subject Re: Deadlock in libpq
Date
Msg-id AANLkTimsJMqAProrivdku4jhJBC-7TpEv+QAXoGasNVB@mail.gmail.com
Whole thread Raw
In response to Re: Deadlock in libpq  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Deadlock in libpq  (Erik Hesselink <hesselink@gmail.com>)
List pgsql-general
On Thu, Mar 24, 2011 at 11:57 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 11:52 AM, Merlin Moncure <mmoncure@gmail.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

pgsql-general by date:

Previous
From: salah jubeh
Date:
Subject: Re: which view is used another views
Next
From: Yang Zhang
Date:
Subject: Default permissions for CREATE SCHEMA/TABLE?