On Mon, Jan 06, 2003 at 11:58:17AM -0500, Tom Lane wrote:
>
> AFAIK, libpq is thread-safe already, it's just not thread-aware.
> What you'd presumably want is a wrapper layer that adds a mutex to
> prevent multiple threads from manipulating a PGconn at the same time.
> Couldn't this be done without touching libpq at all?
In fact it'd probably be better to do it without touching libpq at all,
so the application can tune for the level of thread-safety it needs.
There's no point in locking a PGresult for every time the application
wants to read a field--it'd be unacceptably slow yet some applications
may want to do it. But I'm sure this has been discussed in that other
threading thread...
Having a thread-aware wrapper multiplex a PGconn between multiple
client threads using the nonblocking functions probably isn't going to
wash either, because nonblocking operation isn't quite the same as fully
asynchronous. And even if the backend protocol allows for it, there's
no great benefit since the threads would still be waiting on the same
socket and the same backend. Better to give each thread its own PGconn
and its own file descriptor to block on, if needed.
Jeroen