Content-Type: text/plain;
  charset="iso-8859-1"
From: Philip Yarra <philip@utiba.com>
Organization: Utiba
To: Lee Kindness <lkindness@csl.co.uk>
Subject: Re: ECPG still having thread problems on Linux
Date: Thu, 26 Jun 2003 11:19:09 +1000
User-Agent: KMail/1.4.3
Cc: pgsql-interfaces@postgresql.org
References: <200306241825.32527.philip@utiba.com>
	<16121.27884.841077.431930@kelvin.csl.co.uk>
In-Reply-To: <16121.27884.841077.431930@kelvin.csl.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200306261119.09242.philip@utiba.com>

On Wed, 25 Jun 2003 07:35 pm, Lee Kindness wrote:
> Philip, both your SELECTs are using the same database connection (and
> it's undefined which one it is) without any locking. You need to add
> "AT clauses" to specify an explicit connection. See attached diff.

Ah, that'd be it. I spent some time debugging last night, and I'd realised =
the=20
problem lay in the fact that the preproc was outputting NULL as the=20
connection name, but was unsure why. Your changes allowed both threads to=
=20
complete their inserts, which is great news for us!

I'll add that "AT" clause to my list of updates for the documentation - it=
=20
might be important. It's kinda.... absent... from the manual.=20

I might also add a section on using pthreads with ECPG, since people portin=
g=20
from Informix or Sybase might require such info up front.

> However, i've not tried it... I'll try and get some time!

That'd be great if you could... there appears to still be a problem occurri=
ng=20
at "EXEC SQL DISCONNECT con_name". I'll look into it tonight if I can.

All this does kinda raise the interesting question of why it worked at all =
on=20
FreeBSD... probably different scheduling and blind luck, I suppose.

Thanks for the reponse - I'm a happy man. By 7.4, we should be able to star=
t=20
porting our apps to Postgres in earnest.

Regards, Philip.