FAQ
Hi, all

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?


ODBC specilization said:
---------------------------
On multithread operating systems, drivers must be thread-safe. That is, it
must be possible for applications to use the same handle on more than one
thread. How this is achieved is driver-specific, and it is likely that
drivers will serialize any attempts to concurrently use the same handle on
two different threads.

Applications commonly use multiple threads instead of asynchronous
processing. The application creates a separate thread, calls an ODBC
function on it, and then continues processing on the main thread. Rather
than having to continually poll the asynchronous function, as is the case
when the SQL_ATTR_ASYNC_ENABLE statement attribute is used, the application
can simply let the newly created thread finish.

Functions that accept a statement handle and are running on one thread can
be canceled by calling SQLCancel with the same statement handle from another
thread. Although drivers should not serialize the use of SQLCancel in this
manner, there is no guarantee that calling SQLCancel will actually cancel
the function running on the other thread.



Any ideas?

thanks


regards
Fly.Li

Search Discussions

  • Robert Haas at May 21, 2009 at 4:17 am

    On Thu, May 21, 2009 at 12:04 AM, Fly.Li 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 21, '09 at 4:08a
activeMay 21, '09 at 4:17a
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Robert Haas: 1 post Fly.Li: 1 post

People

Translate

site design / logo © 2022 Grokbase