Re: [HACKERS] thread-safe libpq and DBD::Pg - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: [HACKERS] thread-safe libpq and DBD::Pg
Date
Msg-id 1623.902601037@sss.pgh.pa.us
Whole thread Raw
In response to thread-safe libpq and DBD::Pg  (Goran Thyni <goran@bildbasen.se>)
Responses Re: [HACKERS] thread-safe libpq and DBD::Pg  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
Goran Thyni <goran@bildbasen.se> writes:
> Has anyone any experience of the thread-safeness of libpq?

PQconnectdb() is not thread-safe, because it scribbles temporary
data in the static PQconninfoOptions array.  You can get around
that easily enough by not using PQconnectdb (or PQconndefaults)
--- use PQsetdbLogin() instead.  In any case the problem exists
only if different threads try to open database connections
at the same time.

As far as I can think at the moment, ordinary operations while
the database connection is open should be thread safe.  That's
assuming that your libc (esp. malloc/free) is thread safe of course.
It also assumes that only one thread is using any one PGconn
object (at a time, anyway).  Multiple threads using the same
PGconn to issue concurrent requests definitely will not work.

There is also some thread risk during connection shutdown because
libpq momentarily commandeers the SIGPIPE handler.  I am thinking
it'd be nice to get rid of that code if possible --- see discussion
from a couple weeks ago on the hackers (or was it interfaces?) list.


I had thought a little bit about ripping out PQconnectdb's use of
changeable fields in PQconninfoOptions, but it looks like this
could break applications that access PQconninfoOptions.
Does anyone have any feelings about that, pro or con?

            regards, tom lane

pgsql-interfaces by date:

Previous
From: Brook Milligan
Date:
Subject: Re: [INTERFACES] DBF2PG
Next
From: Tom Lane
Date:
Subject: libpq cleanup for SIGPIPE and stderr concerns