X-Original-To: pgsql-interfaces@postgresql.org
Received: from spampd.localdomain (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP
	id 71B24475F16; Wed, 23 Apr 2003 20:25:33 -0400 (EDT)
Received: from cpc-gw2.cpc.net.au (unknown [210.9.248.93])
	by postgresql.org (Postfix) with ESMTP
	id F1656475E4D; Wed, 23 Apr 2003 20:25:31 -0400 (EDT)
Received: from utiba.com (IDENT:root@ser1.cpc.net.au [192.168.0.19])
	by Utiba Mail Gateway (2.2.2) with ESMTP id h3NNKXP00664;
	Thu, 24 Apr 2003 09:20:33 +1000
Received: from Utiba Mail Thingy
	by utiba.com (Dunno/1.1.2) with ESMTP id KAA26975;
	Thu, 24 Apr 2003 10:25:33 +1000
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 thread-safety
Date: Thu, 24 Apr 2003 10:17:15 +1000
User-Agent: KMail/1.4.1
Cc: Lee Kindness <lkindness@csl.co.uk>,
 Michael Meskes <meskes@postgresql.org>,
	pgsql-interfaces@postgresql.org
References: <200303280200.h2S20N218363@candle.pha.pa.us>
	<200303281749.04746.philip@utiba.com>
	<16038.21258.950904.455466@kelvin.csl.co.uk>
In-Reply-To: <16038.21258.950904.455466@kelvin.csl.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200304241017.15309.philip@utiba.com>
X-Spam-Status: No, hits=-38.9 required=5.0
	tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL
	autolearn=ham	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-Archive-Number: 200304/157
X-Sequence-Number: 4096

On Wed, 23 Apr 2003 18:47, Lee Kindness wrote:
> Even with this patch you'll still be limited by the underlying
> libpq. So for example you cannot share a connection between threads
> without implementing locking to prevent multiple access to that
> connection.

Oh yes, I figured that. Each thread in this application opens its own=20
connection, so this ought not to be the issue. Each DB insert actually gets=
=20
the data into the table, but 2 of the 3 threads stop after that... possibly=
=20
due to concurrently accessing sections of the sqlca struct? (that's just a=
=20
guess though)

Our code is a bit tricky to get running - I might see if I can create a sim=
ple=20
test harness to duplicate the problem and post it to you.

Regards, Philip.