Re: [INTERFACES] libpq + multiple connections ... - Mailing list pgsql-interfaces

On Mon, 29 Nov 1999 eem21@cam.ac.uk wrote:

> 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?

If you can get a patch in so that we can test it, would love to get a
release out by ... oh ... end of week? :)

Anyone object overly?

> 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 <tgl@sss.pgh.pa.us> wrote:
> >> 
> >> > The Hermit Hacker <scrappy@hub.org> 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 
> > 
> 
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


************