Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org
	(8.8.8/8.7.5) with ESMTP id OAA13011;
	Sat, 8 Aug 1998 14:30:58 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA01625;
	Sat, 8 Aug 1998 14:30:38 -0400 (EDT)
To: Goran Thyni <goran@bildbasen.se>
cc: pgsql-interfaces@postgreSQL.org,
	PostgreSQL-development <hackers@postgreSQL.org>
Subject: Re: [HACKERS] thread-safe libpq and DBD::Pg 
In-reply-to: Your message of Fri, 07 Aug 1998 18:19:38 +0000
	<35CB453A.3646F3B6@bildbasen.se>
Date: Sat, 08 Aug 1998 14:30:37 -0400
Message-ID: <1623.902601037@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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