Re: PGconn thread safety

From: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>
To: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
Cc: Lee Kindness <lkindness(at)csl(dot)co(dot)uk>, pgsql-general(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: PGconn thread safety
Date: 2003-02-07 09:14:24
Message-ID: 15939.30960.430288.147731@kelvin.csl.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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:
> On Friday 07 February 2003 12:44 pm, you wrote:
> > Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message will trillich 2003-02-07 10:45:26 inherited, unique serial field...
Previous Message will trillich 2003-02-07 08:58:34 Re: converting Oracle to postgres