Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)...

Lee Kindness wrote:
> Philip Yarra writes:
>  > Unlike the libpq C interface, there is no "connection" variable maintained in 
>  > ECPG... instead, ECPG internally maintains a global list of open connections. 
>  > When a client application issues an EXEC SQL, a connection is retrieved from 
>  > the list, and the SQL statement is executed on that connection. The first 
>  > connection in the list is the "default" connection, so if you don't specify a 
>  > named connection using "AT conn_name" ECPG grabs the first connection in the 
>  > list.
>  > 
>  > I'm pretty sure what happens when you issue EXEC SQL SET CONNECTION is that it 
>  > sets the the default connection, so each of your threads would simply have 
>  > shuffled the default connection. Then when each thread attempts to EXEC SQL 
>  > they grab the same connection... whichever connection was made the default by 
>  > the last thread to issue EXEC SQL SET CONNECTION.
>  > 
>  > I believe this behaviour is consistent with other DBMS implementations of 
>  > embedded SQL, but I'm shooting from the hip.
> 
> Not sure on the consistency, that's one thing ESQL/C rarely is!
> 
> Anyway you're right regarding the SET CONNECTION behaviour. However
> it'd be fairly simple to change things such that each thread keeps
> track of its "current" connection (set by connecting and SET
> CONNECTION) by using thread local storage.
> 
> It'd be a definite improvement over having to specify the connection
> on each call!
> 
> I'll probably do this at some point, but since i'm off to India on
> Monday for the rest of December it'll not be till the New Year at the
> earliest!

Added to TODO and documented.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073