Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)... - Mailing list pgsql-interfaces

From Demetres Pantermalis
Subject Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)...
Date
Msg-id NDBBLJPIEGAHHANHMMBBMENCDBAA.dpant@intracom.gr
Whole thread Raw
In response to Re: Possible bug in ECPGlib thread-safety (Postgres  (Philip Yarra <philip@utiba.com>)
Responses Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)...
List pgsql-interfaces
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 <conn> followed by the inserts
is
> used, instead of the"EXEC SQL AT <conn> ..." 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.
>




pgsql-interfaces by date:

Previous
From: Philip Yarra
Date:
Subject: Re: Possible bug in ECPGlib thread-safety (Postgres
Next
From: Gerhard Häring
Date:
Subject: Re: 7.4 and Pygresql