On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads. I'm largely there with ecpg (globals
are protected, a sqlca for each thread), but of course it relies on
libpq which needs work to share a connection between thrreads.

Relying on thread experience from a few years back on Solaris I had
assumed I could just use the pthread_* routines in the shared
libraries and they would reference the weak symbols in libc, rather
than explicitly pull in libpthread. If the application using the
library linked to libpthreads then the 'real' thread routines would be
activated, single threaded apps wouldn't need link to
libpthread... However there seems to be no standard to which pthread_*
routines are available as weak symbols in libc (Linux and Solaris
differ).

So a couple of questions to decide the course of this work:

1. It's looking likely that the libraries will need to link to
libpthread, and as a result anything linking to the libraries will
need to link to libpthread too. Will this be accepted in a patch? A
similar problem has cropt up with the perl integration recently too
(i.e. the Perl developers have decided to link in libpthread).

2. Is their any mileage in using an abstraction layer - ACE, npr? A
Bit OTT for what i'm doing, but...

3. Am I wasting my time?

I think making the PostgreSQL libraries thread-safe/aware is very
worthwhile, but a lot of hurdles...

Thanks, Lee.

Search Discussions

  • Tom Lane at Jan 6, 2003 at 4:58 pm

    Lee Kindness writes:
    On a slightly related note to the other threads thread [sic] going
    on... Over the Christmas/New Year break i've been looking into making
    the PostgreSQL client libraries (in particular libpq and ecpg)
    thread-safe - that is they can safely be used by a program which
    itself is using mutliple threads. I'm largely there with ecpg (globals
    are protected, a sqlca for each thread), but of course it relies on
    libpq which needs work to share a connection between thrreads.
    AFAIK, libpq is thread-safe already, it's just not thread-aware.
    What you'd presumably want is a wrapper layer that adds a mutex to
    prevent multiple threads from manipulating a PGconn at the same time.
    Couldn't this be done without touching libpq at all?
    1. It's looking likely that the libraries will need to link to
    libpthread, and as a result anything linking to the libraries will
    need to link to libpthread too. Will this be accepted in a patch?
    If the patch requires pthread and not any other form of thread support,
    probably not. See nearby threading thread ;-)

    In general I'd be unhappy with doing anything to libpq that forces
    non-threaded clients to start depending on libpthread (or other thread
    libraries). Thus the idea of a wrapper seems more appealing to me.

    regards, tom lane
  • Jeroen T. Vermeulen at Jan 6, 2003 at 5:13 pm

    On Mon, Jan 06, 2003 at 11:58:17AM -0500, Tom Lane wrote:

    AFAIK, libpq is thread-safe already, it's just not thread-aware.
    What you'd presumably want is a wrapper layer that adds a mutex to
    prevent multiple threads from manipulating a PGconn at the same time.
    Couldn't this be done without touching libpq at all?
    In fact it'd probably be better to do it without touching libpq at all,
    so the application can tune for the level of thread-safety it needs.
    There's no point in locking a PGresult for every time the application
    wants to read a field--it'd be unacceptably slow yet some applications
    may want to do it. But I'm sure this has been discussed in that other
    threading thread...

    Having a thread-aware wrapper multiplex a PGconn between multiple
    client threads using the nonblocking functions probably isn't going to
    wash either, because nonblocking operation isn't quite the same as fully
    asynchronous. And even if the backend protocol allows for it, there's
    no great benefit since the threads would still be waiting on the same
    socket and the same backend. Better to give each thread its own PGconn
    and its own file descriptor to block on, if needed.


    Jeroen
  • Lee Kindness at Jan 6, 2003 at 5:28 pm

    Tom Lane writes:
    Lee Kindness <lkindness@csl.co.uk> writes:
    On a slightly related note to the other threads thread [sic] going
    on... Over the Christmas/New Year break i've been looking into making
    the PostgreSQL client libraries (in particular libpq and ecpg)
    thread-safe - that is they can safely be used by a program which
    itself is using mutliple threads. I'm largely there with ecpg (globals
    are protected, a sqlca for each thread), but of course it relies on
    libpq which needs work to share a connection between thrreads.
    >
    AFAIK, libpq is thread-safe already, it's just not thread-aware.
    What you'd presumably want is a wrapper layer that adds a mutex to
    prevent multiple threads from manipulating a PGconn at the same time.
    Couldn't this be done without touching libpq at all?
    Certainly, it could. I've not fully investigated the current failings
    of libpq WRT to threading yet. But it's certainly a bit more than I
    stated above. I don't know where the statement that libpq is thread
    safe originated from (I see it's on the website). but at a quick
    glance I believe that krb4, krb5, PQoidStatus(),
    PQsetClientEncoding(), winsock_strerror() need more though
    investigation and non-thread-safe fuctions are also being used (at a
    glance gethostbyname() and strtok()).
    1. It's looking likely that the libraries will need to link to
    libpthread, and as a result anything linking to the libraries will
    need to link to libpthread too. Will this be accepted in a patch?
    If the patch requires pthread and not any other form of thread support,
    probably not. See nearby threading thread ;-)
    In general I'd be unhappy with doing anything to libpq that forces
    non-threaded clients to start depending on libpthread (or other thread
    libraries). Thus the idea of a wrapper seems more appealing to me.
    Okay, but what about ecpg? Thread-local sqlca instances would be a
    real benefit, guess Michael and Christof are the guys to talk to?

    I suppose the real problem is the needed baggage with this - the
    autoconf macros will be a nightmare!

    Thanks, Lee.
  • Bruce Momjian at Jan 6, 2003 at 5:49 pm
    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 have been making
    marginal thread-safe improvements over the years.

    ---------------------------------------------------------------------------

    Lee Kindness wrote:
    Tom Lane writes:
    Lee Kindness <lkindness@csl.co.uk> writes:
    On a slightly related note to the other threads thread [sic] going
    on... Over the Christmas/New Year break i've been looking into making
    the PostgreSQL client libraries (in particular libpq and ecpg)
    thread-safe - that is they can safely be used by a program which
    itself is using mutliple threads. I'm largely there with ecpg (globals
    are protected, a sqlca for each thread), but of course it relies on
    libpq which needs work to share a connection between thrreads.
    AFAIK, libpq is thread-safe already, it's just not thread-aware.
    What you'd presumably want is a wrapper layer that adds a mutex to
    prevent multiple threads from manipulating a PGconn at the same time.
    Couldn't this be done without touching libpq at all?
    Certainly, it could. I've not fully investigated the current failings
    of libpq WRT to threading yet. But it's certainly a bit more than I
    stated above. I don't know where the statement that libpq is thread
    safe originated from (I see it's on the website). but at a quick
    glance I believe that krb4, krb5, PQoidStatus(),
    PQsetClientEncoding(), winsock_strerror() need more though
    investigation and non-thread-safe fuctions are also being used (at a
    glance gethostbyname() and strtok()).
    1. It's looking likely that the libraries will need to link to
    libpthread, and as a result anything linking to the libraries will
    need to link to libpthread too. Will this be accepted in a patch?
    If the patch requires pthread and not any other form of thread support,
    probably not. See nearby threading thread ;-)
    In general I'd be unhappy with doing anything to libpq that forces
    non-threaded clients to start depending on libpthread (or other thread
    libraries). Thus the idea of a wrapper seems more appealing to me.
    Okay, but what about ecpg? Thread-local sqlca instances would be a
    real benefit, guess Michael and Christof are the guys to talk to?

    I suppose the real problem is the needed baggage with this - the
    autoconf macros will be a nightmare!

    Thanks, Lee.

    ---------------------------(end of broadcast)---------------------------
    TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
    --
    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
  • Tom Lane at Jan 6, 2003 at 5:53 pm

    Bruce Momjian 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.

    regards, tom lane
  • Lee Kindness at Jan 7, 2003 at 11:20 am

    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.

    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.

    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).

    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.

    Ta, Lee.
  • Bruce Momjian at Jan 7, 2003 at 3:18 pm

    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, Pennsylvania 19073
  • Lee Kindness at Jan 7, 2003 at 4:12 pm

    Bruce Momjian writes:
    Lee Kindness wrote:
    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.
    Some functions in the C library (and other common system libraries)
    are defined in such a way to make their implementation
    non-reentrant. Normally this is due to return values being supplied in
    a static buffer which is overwritten by the subsequent call, or the
    calls relying on static data between calls. A list such functions
    would include:

    asctime crypt ctime drand48 ecvt encrypt erand48 fcvt fgetgrent
    fgetpwent fgetspent getaliasbyname getaliasent getdate getgrent
    getgrgid getgrnam gethostbyaddr gethostbyname gethostbyname2
    gethostent getlogin getnetbyaddr getnetbyname getnetent getnetgrent
    getprotobyname getprotobynumber getprotoent getpwent getpwnam getpwuid
    getservbyname getservbyport getservent getspent getspnam getutent
    getutid getutline gmtime hcreate hdestroy hsearch initstate jrand48
    lcong48 localtime lrand48 mrand48 nrand48 ptsname qecvt qfcvt rand
    random readdir readdir64 seed48 setkey setstate sgetspent srand48
    srandom strerror strtok tmpnam ttyname

    to one degree or another. The important ones to watch for are: ctime,
    localtime, asctime, gmtime, readdir, strtok and tmpnam. Now these
    functions are often augmented by a _r partner which fixes their API to
    allow their implementations to be reentrant.

    After a quick grep libpq could be using crypt, gethostbyname, random,
    strerror, encrypt, getpwuid, rand and strtok. As you rightly note, ins
    ome cases the correct fix is to use alternative functions and not the
    _r versions - this avoids lots of ifdefs!

    L.
  • Lee Kindness at Jan 9, 2003 at 2:14 pm
    Guys, just posted patches for libpq to address thread-safe issues. Now
    uses strerror_r(), gethostbyname_r(), getpwuid_r() and crypt_r() where
    available. Passes all tests on Linux and Solaris.

    Any comments let me know - my first major(ish) outing in the
    PostgreSQL source, in particular I'm not use in the configure stuff is
    100% right...

    Patches also at:

    http://services.csl.co.uk/postgresql/diffs-20030109-configure.txt.gz
    http://services.csl.co.uk/postgresql/diffs-20030109-libpq.txt.gz

    Thanks, Lee.

    Lee Kindness writes:
    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. >
    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. >
    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). >
    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. >
    Ta, Lee.
  • Lee Kindness at Jan 9, 2003 at 3:27 pm
    Tom,

    Tom Lane writes:
    Lee Kindness <lkindness@csl.co.uk> writes:
    + #define _THREAD_SAFE
    + #define _REENTRANT
    + #define _POSIX_PTHREAD_SEMANTICS
    What is this stuff, and why isn't it wrapped in any sort of
    platform-specific test? If it's needed, why is it in only one .c
    file?
    It's actually in libpq-int.h too... The correct way for this is to
    compile with the compilers specific thread flags, however the downside
    to this has already been discussed. Depending on the system one, or a
    combination of those flags will turn on some magic such as errno being
    a function call rather than a global variable. This is needed to make
    the library thread safe.

    On a second look libpq-int.h isn't the best place for this (hence it
    also appears in one of the C files), it needs to be done in each C
    file before any of the system headers are included - a libpq-threads.h
    header? Would this be ok?

    Do do things 100% right we'd need to detect compiler thread flags and
    compile with them...
    Also, haven't you broken SOCK_STRERROR for the Windows case?
    Sorry, I seem to have forgotton to update the prototype in win32.h to
    match the updated function. Updated diff attached (and online).

    Lee.
  • Lamar Owen at Jan 6, 2003 at 7:01 pm

    On Monday 06 January 2003 12:28, Lee Kindness wrote:
    Tom Lane writes:
    Lee Kindness <lkindness@csl.co.uk> writes:
    are protected, a sqlca for each thread), but of course it relies on
    libpq which needs work to share a connection between thrreads.
    AFAIK, libpq is thread-safe already, it's just not thread-aware.
    Couldn't this be done without touching libpq at all?
    Certainly, it could. I've not fully investigated the current failings
    of libpq WRT to threading yet. But it's certainly a bit more than I
    stated above. I don't know where the statement that libpq is thread
    safe originated from (I see it's on the website). but at a quick
    glance I believe that krb4, krb5, PQoidStatus(),
    PQsetClientEncoding(), winsock_strerror() need more though
    investigation and non-thread-safe fuctions are also being used (at a
    glance gethostbyname() and strtok()).
    Lee, see the AOLserver source code. AOLserver (www.aolserver.com) is a
    multithreaded dynamic web server that supports pooled database connections.
    One of the supported databases is PostgreSQL (I maintain the driver,
    currently). It's dual licensed (AOLserver Public License and GPL). I've not
    yet seen a problem that could be traced to libpq not being threadsafe. And
    AOLserver certainly would show a non-threadsafe problem, particularly with
    sites running OpenACS, which can easily beat the database to death.

    BTW: thanks for the Bison RPMs. And I believe the PGDG is appropriate as
    well. :-)
    --
    Lamar Owen
    WGCR Internet Radio
    1 Peter 4:11

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJan 6, '03 at 4:33p
activeJan 9, '03 at 3:27p
posts12
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase