> [] On Behalf Of Tsunakawa,
> Takayuki
> The following page says:
> t-connection
> --------------------------------------------------
> EXEC SQL AT connection-name SELECT ...;
> If your application uses multiple threads of execution, they cannot share
> a connection concurrently. You must either explicitly control access to
> the connection (using mutexes) or use a connection for each thread. If each
> thread uses its own connection, you will need to use the AT clause to specify
> which connection the thread will use.
> EXEC SQL SET CONNECTION connection-name;
> ...It is not thread-aware.
> --------------------------------------------------
> What does this mean by "not thread-aware?"  Does SET CONNECTION in one
> thread change the current connection in another thread?
> It doesn't look so, because the connection management and SQL execution
> in ECPG uses thread-specific data (TSD) to get and set the current connection,
> like this:

The ECPG code sets and gets the current connection to/from the TSD, so SET 
CONNECTION is thread-aware.  I could confirm that like this:

threadA: CONNECT AS conA
threadB: CONNECT AS conB
threadA: CONNECT AS conC
threadA & threadB: SELECT pg_backend_pid() ... each thread displays different 
threadA & threadB: SELECT pg_backend_pid() ... each thread displays different 
pids, with thread outputting the same pid as before

So the doc seems to need fix.  The patch is attached.

Takayuki Tsunakawa

Attachment: ecpg_setconn.patch
Description: ecpg_setconn.patch

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to