On Thu, Mar 24, 2011 at 20:38, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Thu, Mar 24, 2011 at 11:57 AM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: >> On Thu, Mar 24, 2011 at 11:52 AM, Merlin Moncure <mmoncure@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
