pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Philip Yarra <philip@utiba.com>
To: Demetres Pantermalis <dpant@intracom.gr>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)...
Date: Fri, 5 Dec 2003 09:44:19 +1100
Message-ID: <200312050944.19240.philip@utiba.com> (raw)
In-Reply-To: <NDBBLJPIEGAHHANHMMBBMENCDBAA.dpant@intracom.gr>
References: <NDBBLJPIEGAHHANHMMBBMENCDBAA.dpant@intracom.gr>

Hi Demetres,

> Indeed the test_thread.pgc compiles and runs successfully in both mentioned
> 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 
submitted a patch recently to address this issue (unfortunately not in time 
for the 7.4 release).

In light of your question, I might add some detail related to SET CONNECTION.

> 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 
think documenting it clearly would suffice.

The reason for this is below (I'm going from memory here, if I get this wrong 
can someone correct me please?)

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.

Let me know if there are any other specific things you think ought to be in 
the documentation too, and I will try to add them.

Regards, Philip Yarra.





view thread (15+ messages)  latest in thread

Message-ID: <200312050944.19240.philip@utiba.com>
Permalink:  ../200312050944.19240.philip@utiba.com/
Also on:    postgresql.org/message-id/200312050944.19240.philip@utiba.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: philip@utiba.com, dpant@intracom.gr
  Subject: Re: Possible bug in ECPGlib thread-safety (Postgres 7.4)...
  In-Reply-To: <200312050944.19240.philip@utiba.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox