Skip site navigation (1) Skip section navigation (2)

Re: multiple threads using one connection

From: Philip Yarra <philip(at)utiba(dot)com>
To: pgsql-interfaces(at)postgresql(dot)org
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Alvaro Herrera <alvherre(at)commandprompt(dot)com>,Robert Gruszka <rgruszka(at)power(dot)com(dot)pl>
Subject: Re: multiple threads using one connection
Date: 2006-03-01 00:18:13
Message-ID: 200603011118.14079.philip@utiba.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
On Wed, 1 Mar 2006 05:17 am, Bruce Momjian wrote:
> Just to clarify, libpq is thread-safe is each thread uses its own
> connection object.

Hope it's okay if I clarify this a little further, Bruce...

Robert, I think you *should* be able to use the same connection from multiple 
threads so long as you do your own work to avoid concurrent use of the 
connection. I'm sorry, I know less than nothing about Ada, but in C terms 
you'd be using a mutex, acquiring it before your thread issues a statement on 
the connection, reading back all data etc., then releasing the mutex. Other 
threads can then acquire the mutex and use the connection. I assume Ada 
provides some similar sort of concurrency control.

On a side note, the preferred way is to use a connection per thread... and 
given the overhead of thread creation, ISTM the cost of a connection wouldn't 
be that high... but I assume you have some good reason for doing it this way. 
I suppose a connection pool might be another way you could handle this 
requirement.

I say it *should* work because I know this works with ECPG, and AFAIK it uses 
libpq calls, so should be similar for your language binding, but please test 
it with a sample app before assuming that I know what I'm talking about. Can 
someone correct me if I have this wrong? It's been a while since I had to 
think about this stuff...

Regards, Philip.

-- 

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

-----------------
Utiba Pty Ltd 
This message has been scanned for viruses and
dangerous content by Utiba mail server and is 
believed to be clean.


In response to

pgsql-interfaces by date

Next:From: Josh CloseDate: 2006-03-01 01:13:39
Subject: Re: row description, protocol 3
Previous:From: eleinDate: 2006-03-01 00:17:51
Subject: plpython

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group