Re: [HACKERS] Is ECPG's SET CONNECTION really not thread-aware?

From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> The following page says:
> 
> https://www.postgresql.org/docs/devel/static/ecpg-connect.html#ecpg-se
> 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
thatlike this:
 

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

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

Regards
Takayuki Tsunakawa


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers