Shridhar Daithankar wrote:
> On 17 Jun 2003 at 14:14, Tom Lane wrote:
> > > Then maybe we should make a libpq and a libpq_r, etc.
> >
> > That would be fine with me ... although it's only worth doing if the
> > platform has a libc and a libc_r. Shall we use the existence of libc_r
> > to drive this choice?
>
> I agree with this. If libpq is linked against libc_r for threading and mutex
> functions etc. and postgresql is linked against libc, then things like dblink
> which uses both postgresql and libc run into problem of symbol conflict. I
> experienced this on freeBSD and work around was to switch to linuxthreads which
> is not really good.
>
> If there are two versions of libraries available, we should do both. But that
> adds to bloat for certain.
There are a couple of issues here:
First, ecpg has actual thead creation function calls, so I believe we
will still need a --with-threads configure option, at least to control
ecpg, unless we make threading some kind of ecpg runtime flag.
Second, we have some platforms that generate threaded libpq without any
special flags --- libc is threaded by default and no special compile
flags are required.
So, if we move in the libpq_r direction, we will have some platforms
that don't have libpq_r because they don't need it, and others that
don't have it because they don't support threading or we don't know how
to do threading in our configure tests. This seems very confusing to
me. I wonder if we should just keep the current setup for 7.4 and
collect theading configure information, then revisit this for 7.5.
In the current code, if they ask for threads, they succeed or fail.
With an automatic setup, I am not sure how to communicate to the user
whether they are thread-safe or not. I believe this comes back to
Peter's idea that we don't do things automatically, and if they ask for
something, we should fail if we can't do it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
