Re: PostgreSQL libraries - PThread Support, but not use... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PostgreSQL libraries - PThread Support, but not use...
Date
Msg-id 200301071518.h07FIOY06041@candle.pha.pa.us
Whole thread Raw
In response to Re: PostgreSQL libraries - PThread Support, but not use...  (Lee Kindness <lkindness@csl.co.uk>)
Responses Re: PostgreSQL libraries - PThread Support, but not use...
List pgsql-hackers
Lee Kindness wrote:
> Tom Lane writes:
>  > Bruce Momjian <pgman@candle.pha.pa.us> writes:
>  > > We have definatly had requests for improved thread-safeness for libpq
>  > > and ecpg in the past, so whatever you can do would be a help.  We say
>  > > libpq is thread-safe, but specifically mention the non-threadsafe calls
>  > > in the libpq documentation, or at least we should.
>  > We do:
>  > http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
>  > But Lee's point about depending on possibly-unsafe libc routines is a
>  > good one.  I don't think anyone's gone through the code with an eye to
>  > that.
> 
> Right, so a reasonable angle for me to take is to go through the libpq
> source looking for potential problem areas and use of "known bad"
> functions. I can add autoconf checks for the replacement *_r()
> functions, and use these in place of the traditional ones where
> available.

I am a little confused by the *_r functions.  Are they for all
functions?  BSD/OS doesn't have them, but all our libc functions are
threadsafe except for things like strtok, where they recommend strsep,
and gethostbyname, where they would suggest getaddrinfo, I guess.

> If any function is found to be not thread-safe and cannot be made so
> using standard library calls then it needs to be documented as such
> both in the source and the aforementioned documentation.

Ideally we will find we can get them all fixed in some way.

> This approach avoids any thread library dependencies and documents the
> current state of play WRT thread safety (i.e it's a good, and needed,
> basis for any later work).

Yes, good idea.

> ECPG is a separate issue, and best handled as such (it will need
> thread calls). I'll post a patch for it at a later date so the changes
> are available to anyone who wants to play with ECPG and threads.

Yes, needs to be done too.  Someone was complaining about ecpg not being
thread safe several months ago.  I don't remember the details.

--  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,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: Next platform query: Alphaservers under VMS?
Next
From: Bruce Momjian
Date:
Subject: Re: bug in latest Makefile commit