pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
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
Date: Sat, 08 Aug 1998 20:51:18 -0400
Message-ID: <3278.902623878@sss.pgh.pa.us> (raw)
In-Reply-To: <1623.902601037@sss.pgh.pa.us>

I wrote:
> Goran Thyni <goran@bildbasen.se> writes:
>> Has anyone any experience of the thread-safeness of libpq?

> 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 have removed that SIGPIPE hacking from closePGconn() in a patch
just submitted to pgsql-patches; that's one less thread safety violation
in libpq.  However, whilst I was poking about in the libpq innards I
noticed a couple of other ones :-(.

PQprint() also manipulates the SIGPIPE handler in order to prevent
application termination if the pager subprocess it starts up decides
to quit early.  This is a good thing, I think, but it does create
a problem if the app is multi-threaded and other threads would prefer
a different SIGPIPE setting.  (I suppose if signal handlers are
thread-local in your environment then it's a non-issue anyway.)

I also noticed that PQoidStatus() returns a pointer to a static
char array, which is a classic thread-safety booboo.  I am thinking
that the cleanest solution is for it to copy the OID number into
conn->errorMessage and return a pointer to that.  This would mean
that the value would not be good after the next operation on the
PGconn object, but I wouldn't imagine that any apps hold onto the
pointer very long anyway --- they probably always feed it to atoi
immediately.  (Actually, why the dickens doesn't this routine
return an Oid value directly?  It could return InvalidOid in
case of trouble, just like PQftype does... but I suppose we don't
want to break application code just to make the API a tad cleaner.)

			regards, tom lane



view thread (27+ messages)  latest in thread

Message-ID: <3278.902623878@sss.pgh.pa.us>
Permalink:  ../3278.902623878@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3278.902623878@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: tgl@sss.pgh.pa.us, goran@bildbasen.se, hackers@postgreSQL.org
  Subject: Re: [HACKERS] thread-safe libpq and DBD::Pg
  In-Reply-To: <3278.902623878@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox