From: | Erik Hesselink <hesselink(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Deadlock in libpq |
Date: | 2011-03-25 08:26:16 |
Message-ID: | AANLkTimVjajmc6rChJ=3sRreN60XRLpovzt0Pyd8wEJc@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Mamin | 2011-03-25 11:36:19 | ERROR: type "foo_20110307_id_seq" already exists (expected relation "foo_20110307_id_seq" already exists) |
Previous Message | Shiv | 2011-03-25 04:56:40 | Re: foreign data wrappers |