From: eem21@cam.ac.uk
To: scrappy@hub.org
Cc: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us
Subject: Re: [INTERFACES] libpq + multiple connections ...
Date: Mon, 29 Nov 1999 21:18:58 +0000 (GMT)
Message-ID: <E11sYAg-0002xd-00@orange.csi.cam.ac.uk> (raw)
In-Reply-To: <Pine.BSF.4.21.9911291705320.69193-100000@thelab.hub.org>
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 <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
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: eem21@cam.ac.uk, scrappy@hub.org, tgl@sss.pgh.pa.us
Subject: Re: [INTERFACES] libpq + multiple connections ...
In-Reply-To: <E11sYAg-0002xd-00@orange.csi.cam.ac.uk>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox