From: Frank van Vugt <ftm.van.vugt@foxi.nl>
Organization: Foxi Consultants in Technology BV
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: SOLVED: Multi-threaded Qt app segfaults when using libpq with
	separate connections
Date: Fri, 8 Aug 2003 10:46:10 +0200
User-Agent: KMail/1.5.1
Cc: pgsql-interfaces@postgresql.org
References: <200308041729.13212.ftm.van.vugt@foxi.nl>
	<200308050034.20405.ftm.van.vugt@foxi.nl>
	<13531.1060036862@sss.pgh.pa.us>
In-Reply-To: <13531.1060036862@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200308081046.10157.ftm.van.vugt@foxi.nl>

Hi,

I *finally* nailed this thing, turns out NOT to be a PG problem, more like 
PEBKC.

Tom Lane wrote:
> I get the impression that something is clobbering memory with abandon.

He was write (duh..).


What wasn't clear (at least to me) from the Qt-docs is that a name given to a 
supplementary database connection must be unique, otherwise the new one will 
replace the old one. Expecting to be able to handle the connections by the 
pointers an addDatabase() call returned, I had been creating new connections 
in separate threads whose names weren't always unique.

Since 'connection' here implicates a PGconn structure, I had been 'switching' 
PGconn structures while in use. It seems one can even get away with that for 
a limited number of threads, but at a certain point newly created result 
structures (PGresult, PQntubles, PQnfields, etc.) will be allocated space on 
top of the older structures belonging the replaced connections, which is 
obviously the point where things get very messy....

I've asked the Trolls (Qt) to emphasize this potential problem in their docs.


Thanks to Tom Lane (PostgreSQL) and Harald Fernengel (TrollTech) for their 
pointers ;)


Best,


Frank van Vugt