X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (neptune.hub.org [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 18ECCD1B44A for ; Fri, 5 Dec 2003 09:20:41 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 10353-08 for ; Fri, 5 Dec 2003 05:20:11 -0400 (AST) Received: from internet.csl.co.uk (internet.csl.co.uk [194.130.52.3]) by svr1.postgresql.org (Postfix) with ESMTP id 89773D1B479 for ; Fri, 5 Dec 2003 05:20:08 -0400 (AST) Received: from euphrates.csl.co.uk (host-194-67.csl.co.uk [194.130.52.67]) by internet.csl.co.uk (8.12.8/8.12.8) with ESMTP id hB59JwEY005953; Fri, 5 Dec 2003 09:19:58 GMT Received: from kelvin.csl.co.uk by euphrates.csl.co.uk (8.9.3/ConceptI 2.4) id JAA24926; Fri, 5 Dec 2003 09:19:57 GMT Received: from kelvin.csl.co.uk (localhost.localdomain [127.0.0.1]) by kelvin.csl.co.uk (8.12.8/8.12.8) with ESMTP id hB59JuuK014225; Fri, 5 Dec 2003 09:19:56 GMT Received: (from lkind@localhost) by kelvin.csl.co.uk (8.12.8/8.12.8/Submit) id hB59JpPL014220; Fri, 5 Dec 2003 09:19:51 GMT From: Lee Kindness MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16336.19895.354907.412172@kelvin.csl.co.uk> Date: Fri, 5 Dec 2003 09:19:51 +0000 To: Philip Yarra Cc: "Demetres Pantermalis" , , Lee Kindness Subject: Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)... In-Reply-To: <200312050944.19240.philip@utiba.com> References: <200312050944.19240.philip@utiba.com> X-Mailer: VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200312/18 X-Sequence-Number: 4627 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! L.