PGconn thread safety
does anyone know if PGconns are safe to use from multiple threads of control?
-a
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ahoward@fsl.noaa.gov
| Phone: 303-497-7238
| Fax: 303-497-7259
====================================
On Thu, 2003-02-06 at 21:19, ahoward wrote:
does anyone know if PGconns are safe to use from multiple threads of control?
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
"libpq is thread-safe as of PostgreSQL 7.0, so long as no two threads
attempt to manipulate the same PGconn object at the same time."
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway <neilc@samurai.com> writes:
On Thu, 2003-02-06 at 21:19, ahoward wrote:
does anyone know if PGconns are safe to use from multiple threads of control?
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
"libpq is thread-safe as of PostgreSQL 7.0, so long as no two threads
attempt to manipulate the same PGconn object at the same time."
That's the theory anyway. I believe it actually is free of unsafe uses
of static variables. However, someone recently pointed out that it uses
some libc routines that probably aren't thread-safe; so there's some
cleanup yet to do before we can claim real thread safety.
regards, tom lane
On Friday 07 February 2003 12:44 pm, you wrote:
Neil Conway <neilc@samurai.com> writes:
That's the theory anyway. I believe it actually is free of unsafe uses
of static variables. However, someone recently pointed out that it uses
some libc routines that probably aren't thread-safe; so there's some
cleanup yet to do before we can claim real thread safety.
Well, I ran a mutlithreaded test where around 30 connections were hammered in
a mutlihtreaded servers using libpq for 100,000 transactions. I didn't notice
any data inconsistency.
Only noticable thing was that postgresql was not returning even simplest
result in less than 200 ms. So in order to achieve a good throughput, I had
to up the number of connections. The max throughput. was 200ms/no. of
connections.
but that is a different issue..
Shridhar
Well the areas I have patched would have /potentially/ caused
inaccurate error messages (using global errno). Also potential
corruption on connect to database if 2+ threads were trying to do this
at once - a non-threadsafe fucntion was being used to retrieve all
local usernames.
I've been a bit busy of late, the code itself is submitted to
pgsql-patches but configure work is still to be done.
L.
Shridhar Daithankar writes:
Show quoted text
On Friday 07 February 2003 12:44 pm, you wrote:
Neil Conway <neilc@samurai.com> writes:
That's the theory anyway. I believe it actually is free of unsafe uses
of static variables. However, someone recently pointed out that it uses
some libc routines that probably aren't thread-safe; so there's some
cleanup yet to do before we can claim real thread safety.Well, I ran a mutlithreaded test where around 30 connections were hammered in
a mutlihtreaded servers using libpq for 100,000 transactions. I didn't notice
any data inconsistency.Only noticable thing was that postgresql was not returning even simplest
result in less than 200 ms. So in order to achieve a good throughput, I had
to up the number of connections. The max throughput. was 200ms/no. of
connections.but that is a different issue..
Shridhar
On Fri, 7 Feb 2003, Shridhar Daithankar wrote:
On Friday 07 February 2003 12:44 pm, you wrote:
Neil Conway <neilc@samurai.com> writes:
That's the theory anyway. I believe it actually is free of unsafe uses
of static variables. However, someone recently pointed out that it uses
some libc routines that probably aren't thread-safe; so there's some
cleanup yet to do before we can claim real thread safety.
Well, I ran a mutlithreaded test where around 30 connections were hammered =
in=20
a mutlihtreaded servers using libpq for 100,000 transactions. I didn't noti=
ce=20
any data inconsistency.=20
meaning your connections had no semaphore (or other) type thread protection?
-a
Only noticable thing was that postgresql was not returning even simplest=20
result in less than 200 ms. So in order to achieve a good throughput, I had=
=20
to up the number of connections. The max throughput. was 200ms/no. of=20
connections.but that is a different issue..
Shridhar
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ahoward@fsl.noaa.gov
| Phone: 303-497-7238
| Fax: 303-497-7259
====================================
On Fri, 7 Feb 2003, Lee Kindness wrote:
Well the areas I have patched would have /potentially/ caused
inaccurate error messages (using global errno). Also potential
corruption on connect to database if 2+ threads were trying to do this
at once - a non-threadsafe fucntion was being used to retrieve all
local usernames.I've been a bit busy of late, the code itself is submitted to
pgsql-patches but configure work is still to be done.L.
in my connection pool, all connections are made _before_ any thread access
takes place. the pool will be used mostly for cgi programs so i really don't
care about error messages too much (seems like using res = PGExec might fix
this issue?) so it seems like my application may not need thread protection.
-a
Shridhar Daithankar writes:
On Friday 07 February 2003 12:44 pm, you wrote:
Neil Conway <neilc@samurai.com> writes:
That's the theory anyway. I believe it actually is free of unsafe uses
of static variables. However, someone recently pointed out that it uses
some libc routines that probably aren't thread-safe; so there's some
cleanup yet to do before we can claim real thread safety.Well, I ran a mutlithreaded test where around 30 connections were hammered in
a mutlihtreaded servers using libpq for 100,000 transactions. I didn't notice
any data inconsistency.Only noticable thing was that postgresql was not returning even simplest
result in less than 200 ms. So in order to achieve a good throughput, I had
to up the number of connections. The max throughput. was 200ms/no. of
connections.but that is a different issue..
Shridhar
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ahoward@fsl.noaa.gov
| Phone: 303-497-7238
| Fax: 303-497-7259
====================================
On 7 Feb 2003 at 14:40, ahoward wrote:
On Fri, 7 Feb 2003, Shridhar Daithankar wrote:
On Friday 07 February 2003 12:44 pm, you wrote:
Neil Conway <neilc@samurai.com> writes:
That's the theory anyway. I believe it actually is free of unsafe uses
of static variables. However, someone recently pointed out that it uses
some libc routines that probably aren't thread-safe; so there's some
cleanup yet to do before we can claim real thread safety.Well, I ran a mutlithreaded test where around 30 connections were hammered =
in=20
a mutlihtreaded servers using libpq for 100,000 transactions. I didn't noti=
ce=20
any data inconsistency.=20meaning your connections had no semaphore (or other) type thread protection?
I had. But each pgConn object was used in a separate thread. All connections
were created before any threads. So that issue of non-thread safe function to
fetch local user names did not arise, I guess..
Bye
Shridhar
--
The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's
Child", stardate 3497.2