"David O'Farrell" <dave.ofarrell@aersoft.ie> writes:
> "The libpq library allows a single frontend to make multiple
> connections to backend processes. However, the frontend application
> is still a single-threaded process."
> could some clarify to me if this means that a frontend CANNOT open
> several connections from different threads with the current
> implementation of libpq.
It just means that libpq doesn't somehow magically convert a
single-threaded application into a multi-threaded one just becase you
opened more than one connection.
PQconnectdb() is not currently multithreadable, because it relies on a
global variable to hold connection options. (Which is part of the API
for the routine, so I can't easily fix it without risking breaking
applications :-(.) But as far as I know, all the rest of libpq is
multithreadable, by which I mean that different threads can be working
on different connection objects concurrently.
libpq does not know anything about threads, so it does not contain any
interlocking that would make it safe for more than one thread to touch a
given connection object or result object. If you need that, you'll have
to provide a lock associated with each object at the application level.
(Realistically, you'd have to do that anyway. Even if libpq contained
code to serialize access to a connection object, it could only interlock
on a function-call-by-function-call basis. But almost certainly, each
thread will want to lock down the state of the connection object for a
series of operations. For instance, you'd not want another thread to
issue a new PQexec till you'd got done examining the result of the
previous one. libpq couldn't enforce that for you.)
If you need to make connections concurrently, just use PQsetdbLogin()
rather than PQconnectdb().
BTW this all assumes that you have a thread-safe libc; if malloc is
not thread-safe then all bets are off...
> Is there anyone working on multi threading for libpq ?
I don't really see a need for libpq to be thread-aware.
regards, tom lane
