I'm working on bullet-proofing AOLserver's postgres driver.
I've fixed a bunch of weaknesses, but am stumped by the
following...
AOLserver's a multithreaded server, and libpq's database
connection routines aren't threadsafe. It turns out the
environment in which the driver lives doesn't allow me
to ensure that only one thread executes a PQsetdb at a
time, at least without resorting to the specific operating
system's mutexes and cond primitives. The server provides
a nice portable interface for such things but they're
not available to database drivers because in general the
server's not interested in having database drivers do such
things.
That's not a problem for this group, but I'm curious. People
have been using this driver for years, and some use it
heavily (Lamar Owen, for one). Despite the thread unsafeness
of PQsetdb et al, I've never seen a failure in this environment
and I've never heard of folks experiencing such a failure.
So my question's simple - what exactly makes PQsetdb et al
thread unsafe? I'm asking in order to attempt to get a handle
on just how vulnerable the routines are when two threads attempt
to open a database connection simultaneously.
The other question's simple, too - are the implications predictable,
i.e. will (for instance) one of the attemps simply crash or
fail when two or more threads attempt to make a connection? Or
am I looking at something more evil, like silent building of a
connection messed up in some subtle way?
I suspect the answer to the last question is that the result of
doing this is unpredictable, but thought I'd ask.
AOLserver supports external drivers called by a proxy with a
separate process provided for each database connection, but
there are unfortunate performance implications with this
approach. It's designed explicitly for dbs with no threadsafe
C API. This includes Sybase, and in my testing the internal
Postgres driver can feed bytes to the server about three times
as fast as the external driver written for Sybase, so you
can see why I'm reluctant to rewrite the Postgres driver simply
because building a connection's not threadsafe. After all,
unless a backend crashes they only happen when the server's
first fired up. And people aren't seeing problems.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.