Re: How to issure PQexec is thread safety if use a connceion in two threads?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "Fly(dot)Li" <fly2nn(at)126(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to issure PQexec is thread safety if use a connceion in two threads?
Date: 2009-05-21 04:17:38
Message-ID: 603c8f070905202117y60df56ccp1d32845fd4ac7720@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 21, 2009 at 12:04 AM, Fly.Li <fly2nn(at)126(dot)com> wrote:
> Reading libpq code( PQexec() ), I cann't find measure for thread safety.
>
> Read libpq doc, there are some words:
> ---------------------
> One thread restriction is that no two threads attempt to manipulate the same
> PGconn object at the same time. In particular, you cannot issue concurrent
> commands from different threads through the same connection object. (If you
> need to run concurrent commands, use multiple connections.)
> -------------------------------
>
> I dont't think it is a good idea. Should libpq do something for issure the
> true thread safety?

Well, I think the only thing we could really do is serialize access to
the underlying connection object, since the backend can only execute
one query at a time regardless of what libpq does. That would require
some sort of synchronization overhead that would in most cases be
wasted. If someone wants to implement an ODBC layer on top of libpq,
they can protect access to the libpq connection object using a mutex
at that level, which would solve the problem you're concerned about
without imposing an unnecessary overhead on people using libpq
directly from single-threaded applications.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2009-05-21 04:21:40 Re: from_collapse_limit vs. geqo_threshold
Previous Message Robert Haas 2009-05-21 04:10:21 pull raw text of a message by message-id