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 A6FA5D1B4B9 for ; Thu, 4 Dec 2003 22:44:53 +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 39624-06 for ; Thu, 4 Dec 2003 18:44:24 -0400 (AST) Received: from cpc-gw2.cpc.net.au (unknown [210.9.248.93]) by svr1.postgresql.org (Postfix) with ESMTP id BA09CD1B464 for ; Thu, 4 Dec 2003 18:44:19 -0400 (AST) Received: from utiba.com (ser1.cpc.net.au [192.168.0.19]) by Utiba Mail Gateway (2.2.2) with ESMTP id hB4MiM817052; Fri, 5 Dec 2003 09:44:22 +1100 Received: from pc37.cpc.net.au (pc37.cpc.net.au [192.168.0.37]) by Utiba Mail Thingy (0.0.2) with ESMTP id hB4MiK615521; Fri, 5 Dec 2003 09:44:20 +1100 Content-Type: text/plain; charset="iso-8859-1" From: Philip Yarra Organization: Utiba Pty Ltd To: "Demetres Pantermalis" Subject: Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)... Date: Fri, 5 Dec 2003 09:44:19 +1100 User-Agent: KMail/1.4.3 Cc: References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200312050944.19240.philip@utiba.com> X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200312/16 X-Sequence-Number: 4625 Hi Demetres, > Indeed the test_thread.pgc compiles and runs successfully in both mention= ed > platforms. Okay, thanks. > The reason I started this issue, is because in the documentation it is not > clear that the "SET CONNECTION" should not be used in multi-threaded > applications. You're right, the current documentation is not clear on this point... I=20 submitted a patch recently to address this issue (unfortunately not in time= =20 for the 7.4 release). In light of your question, I might add some detail related to SET CONNECTIO= N. > Anyway, are there any plans to change the behavior of the "SET CONNECTION" > to be as I have expected, in the near future??? I don't think so... the behaviour of SET CONNECTION is a bit confusing, but= I=20 think documenting it clearly would suffice. The reason for this is below (I'm going from memory here, if I get this wro= ng=20 can someone correct me please?) Unlike the libpq C interface, there is no "connection" variable maintained = in=20 ECPG... instead, ECPG internally maintains a global list of open connection= s.=20 When a client application issues an EXEC SQL, a connection is retrieved fro= m=20 the list, and the SQL statement is executed on that connection. The first= =20 connection in the list is the "default" connection, so if you don't specify= a=20 named connection using "AT conn_name" ECPG grabs the first connection in th= e=20 list. I'm pretty sure what happens when you issue EXEC SQL SET CONNECTION is that= it=20 sets the the default connection, so each of your threads would simply have= =20 shuffled the default connection. Then when each thread attempts to EXEC SQL= =20 they grab the same connection... whichever connection was made the default = by=20 the last thread to issue EXEC SQL SET CONNECTION. I believe this behaviour is consistent with other DBMS implementations of= =20 embedded SQL, but I'm shooting from the hip. Let me know if there are any other specific things you think ought to be in= =20 the documentation too, and I will try to add them. Regards, Philip Yarra.