From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@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 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 pids threadA: SET CONNECTION conA 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. Regards Takayuki Tsunakawa
ecpg_setconn.patch
Description: ecpg_setconn.patch
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
