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

From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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