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 1EAF1D1B48E for ; Thu, 4 Dec 2003 12:45:42 +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 26103-08 for ; Thu, 4 Dec 2003 08:45:13 -0400 (AST) Received: from mailserv.intranet.gr (mailserv.intranet.GR [146.124.14.106]) by svr1.postgresql.org (Postfix) with ESMTP id E602ED1B4B0 for ; Thu, 4 Dec 2003 08:45:08 -0400 (AST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id hB4CnLF05899 for ; Thu, 4 Dec 2003 14:49:21 +0200 (EET) Received: from alpha.intranet.gr (alpha.intranet.GR [146.124.12.11]) by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id hB4CnIk05880; Thu, 4 Dec 2003 14:49:18 +0200 (EET) Received: from csms (csms [146.124.12.43]) by alpha.intranet.gr (8.11.7p1+Sun/8.11.7) with SMTP id hB4Cvkh06695; Thu, 4 Dec 2003 14:57:46 +0200 (EET) From: "Demetres Pantermalis" To: "Philip Yarra" Cc: Subject: Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)... Date: Thu, 4 Dec 2003 14:47:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200312/14 X-Sequence-Number: 4623 Hi Philip and thanks for your *instant* reply. Indeed the test_thread.pgc compiles and runs successfully in both mentioned platforms. I've tried it many times with many rows (100000 rows). 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. Anyway, are there any plans to change the behavior of the "SET CONNECTION" to be as I have expected, in the near future??? Much obliged!!! Demetres Pantermalis Intracom SA Network Support Systems -----Original Message----- From: Philip Yarra [mailto:philip@utiba.com] Sent: Thursday, December 04, 2003 2:08 PM To: Demetres Pantermalis Cc: pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] Possible bug in ECPGlib thread-safety (Postgres 7.4)... Hi Demetres, I'm the guy whose emails you quoted below! You *must* always use the AT conn_name in a multi-threaded application... using SET CONNECTION will not work. I assume your test results work if you use the thread test application as included (I wrote it, so I'd be interested to know if it works, as I have not tested RH9 and SunOS5.8 (though I tested RH7.3 and SunOS2.6) Regards, Philip Yarra. On Thu, 4 Dec 2003, Demetres Pantermalis wrote: > Dear All, > > trying to run some tests for the thread-safety of the ecpg library, I > modified the test_thread.pgc to be like the one attached (test_thread1.pgc). > > The changes are as follows: > 1) All the connections used for insertions, begin in main function (and not > inside each thread) > 2) The statement "EXEC SQL SET CONNECTION followed by the inserts is > used, instead of the"EXEC SQL AT ..." statement. > 3) A new line for ECPGlog was added. > > The results of executing the code are unexpected. Either a core dump > results, or one of the two threads inserts the rows in the table and the > process never returns to OS prompt, while the other thread seems to insert > the rows, but never commits. > > A log file produced by ECPGlog is also attached. > > Platforms tested: SunOS 5.8 and Linux RH9 (with the same results) > > Any suggestions appreciated. > > PS. I've found out that somebody else had about the same problem, but that > was during testing phase and I assumed that it could have been solved by > now. The links found are: > http://archives.postgresql.org/pgsql-hackers/2003-06/msg00513.php > http://archives.postgresql.org/pgsql-hackers/2003-06/msg00792.php > > Demetres Pantermalis > Intracom SA > Network Support Systems. >