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