Magnus Hagander <mha@sollentuna.net> writes:
>> It is not; the main reason why not is a brain-dead part of
>> the API that exposes modifiable global variables.
> Hmm. Really?
PQconnectdb() is the function that's not thread-safe; if you had
multiple threads invoking PQconnectdb() in parallel you would see a
problem. PQconndefaults() is the function that creates an API problem,
because it exposes the static variable that PQconnectdb() ought not have
had in the first place.
There might be some other problems too, but that's the main one I'm
aware of. If we didn't mind breaking existing apps that use
PQconndefaults(), it would be straightforward to fix...
> Otherwise, I've been darn lucky in the multithreaded stuff I have :-) (I run
> with a different PGconn for each thread, and the PGresult:s are protected by
> CriticalSections (this is Win32)). And if that's it, then I really need to
> fix it...
Seems reasonable. PGconns do need to be per-thread, or else protected
by mutexes, but you can run them in parallel. PGresults are actually
almost read-only, and I've been wondering if they can't be made entirely
so (until destroyed of course). Then you wouldn't need a
CriticalSection. You might want some kind of reference-counting
mechanism for PGresults though.
regards, tom lane