Received: from orange.csi.cam.ac.uk (exim@orange.csi.cam.ac.uk [131.111.8.77]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA85150 for ; Mon, 29 Nov 1999 16:17:26 -0500 (EST) (envelope-from ewan@cam.ac.uk) Received: from cmor.chu.cam.ac.uk ([131.111.202.213] helo=cam.ac.uk) by orange.csi.cam.ac.uk with esmtp (Exim 3.03 #1) id 11sYAg-0002xd-00; Mon, 29 Nov 1999 21:17:19 +0000 Date: Mon, 29 Nov 1999 21:18:58 +0000 (GMT) From: eem21@cam.ac.uk Reply-To: eem21@cam.ac.uk Subject: Re: [INTERFACES] libpq + multiple connections ... To: scrappy@hub.org cc: pgsql-interfaces@postgresql.org, tgl@sss.pgh.pa.us In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: On 29 Nov, The Hermit Hacker wrote: > > Is this something that could *safely* be back-patched to a v6.5.4 release? Well, it's not _supposed_ to have changed the behaviour for existing functions. However, there's been quite a lot of chopping and changing, and I might have lost something somewhere. That said, it would be of great help to me if it made it into a 6.5.x release, and I would thus be willing to test it. I can only test ix86/Linux, unfortunately. When would it be released, if that were the case? BTW, how do I find out about the SGML tags we are using (I've never written any SGML before, only HTML). Ewan. > > On Mon, 29 Nov 1999, E.E. Mellor wrote: > >> --On 29 November 1999, 02:45 -0500 Tom Lane wrote: >> >> > The Hermit Hacker forwards: >> >> Hmm, sorta, I'm a bit troubled, I was trying to add an async connection >> >> function to libpq and I stumbled across some problems. >> > >> > Someone else was already working on that --- check the archives from >> > a few months back. >> >> 'twas me. In fact, it's been ready for ages, but I've had so much on that >> I've not had time to write the docs. I'll do them today for you. >> >> >> It seems that libpq makes use of some static variables, meaning i'm not >> >> sure if it's safe to use libpq for multiple database connections. >> >> What i'm refering to is: >> >> postgresql-6.5.3/src/interfaces/libpq/fe-connect.c >> >> line 79 has a structure that seems to be shared amongst the entire >> >> library, am I likely to stumble upon more stuff that makes it somewhat >> >> dangerous to have more than one active database connection in my program? >> > >> > The PQconnectdb() function uses that static array, meaning that you can't >> > safely run two PQconnectdb() calls in parallel. But you can open two >> > connections in sequence and then use them in parallel; and you can do >> > the opens in parallel if you use one of the older, less-friendly >> > connection-opening calls. There aren't any other non-constant statics >> > in libpq AFAIR. >> >> This is correct. Someone else was looking at thread-safety across the >> whole of libpq, but as far as I'm aware, it's not _guaranteed_ to be >> thread-safe anywhere. My changes allow one to use libpq in a single >> thread, but with multiple connections and without blocking the thread at >> all. >> >> > The static array sucks, I agree, but I don't see any way to get rid of >> > it without changing libpq's API for PQconnectdb() and PQconndefaults(). >> > Do we want to consider doing that (and breaking some apps) for 7.0? >> >> I think it should be possible to arrange it so that these functions still >> exist (but are deprecated and marked as non-thread-safe). I'll leave that >> for others to decide though. >> >> Ewan Mellor. >> > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org >