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
