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

Re: Libpq driver: thread problem

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: Marko Ristola <Marko(dot)Ristola(at)kolumbus(dot)fi>,pgsql-odbc(at)postgresql(dot)org
Subject: Re: Libpq driver: thread problem
Date: 2005-08-12 21:24:40
Message-ID: 200508122124.j7CLOec16547@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-odbc
Dave Page wrote:
> Err, what's been saved? This is part of a discussion re psqlODBC -
> there's no patches here yet, and any that do come of it will be for
> psqlODBC, not the server.

Uh, doesn't libpq have the same issue?

---------------------------------------------------------------------------


> 
> Regards, Dave
> 
> > -----Original Message-----
> > From: pgsql-odbc-owner(at)postgresql(dot)org 
> > [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Bruce Momjian
> > Sent: 12 August 2005 22:12
> > To: Marko Ristola
> > Cc: pgsql-odbc(at)postgresql(dot)org
> > Subject: Re: [ODBC] Libpq driver: thread problem
> > 
> > 
> > This has been saved for the 8.2 release:
> > 
> > 	http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> > 
> > --------------------------------------------------------------
> > -------------
> > 
> > Marko Ristola wrote:
> > > 
> > > I remember, that psqlodbc depends on ANSI C locale features.
> > > ANSI C locale settings are not thread safe.
> > > 
> > > setlocale() functions are not thread safe in Windows and 
> > not in Linux:
> > > 
> > > convert.c:                              saved_locale =
> > > strdup(setlocale(LC_ALL, NULL));
> > > convert.c:                              setlocale(LC_ALL, "C");
> > > convert.c:                              setlocale(LC_ALL, 
> > saved_locale);
> > > convert.c:                              saved_locale =
> > > strdup(setlocale(LC_ALL, NULL));
> > > convert.c:                              setlocale(LC_ALL, "C");
> > > convert.c:                              setlocale(LC_ALL, 
> > saved_locale);
> > > 
> > > They should be replaced with thread safe alternatives, when proven
> > > thread safety
> > > is required. Of course, this might work, if there is only a single
> > > connection
> > > and a single statement with many threads and no other 
> > application feature
> > > depends on the global locale setting.
> > > 
> > > I think, that UTF-8 could be used internally under both 
> > Linux and Windows.
> > > It would simplify the psqlodbc driver. Maybe SQL_ASCII would be the
> > > exception.
> > > Under Linux, there is iconv() function API, that can be 
> > used for the needed
> > > thread safe conversion object.
> > > 
> > > Under Windows, the setlocale() function is thread local, if the
> > > following code
> > > is called:
> > > 
> > > _configthreadlocale(_ENABLE_PER_THREAD_LOCALE);
> > > 
> > > 
> > > Is psqlodbc thread safe in Windows, if that is defined within main()
> > > function?
> > > 
> > > 
> > > There is an example about thread local locales near the 
> > bottom of page
> > > http://msdn2.microsoft.com/library/x99tb11d(en-us,vs.80).aspx
> > > 
> > > I don't know any other thread safe locale API within Windows.
> > > 
> > > Could we use libicu under Linux and Windows? Is it thread safe?
> > > Could we hide the locale details within libpq and just use it's
> > > thread safe features?
> > > 
> > > Marko Ristola
> > > 
> > > 
> > > Bruce Momjian wrote:
> > > 
> > > >Dave Page wrote:
> > > >  
> > > >
> > > >>>The main issue with the flag, as I remember, is to allow multiple
> > > >>>threads to open libpq connections.  If you don't do that, you 
> > > >>>don't need
> > > >>>the flag.
> > > >>>      
> > > >>>
> > > >>In which case it definitely needs fixing. Which may be a 
> > non-trivial
> > > >>task as pthreads on Windows is not currently used by 
> > PostgreSQL, and
> > > >>didn't want to play last time I looked at it :-( However...
> > > >>
> > > >>I did look at this very briefly before speaking to 
> > Magnus. The first
> > > >>problem I ran into was that configure was insisting that 
> > posix signals
> > > >>were needed to enable thread safety. Before I spend lots 
> > of time looking
> > > >>at the code do you know if it is safe for me to assume our signal
> > > >>emaulation will do that job in all the right places? If 
> > so, I guess it's
> > > >>just a case of fixing the pthread detection and linker flags.
> > > >>    
> > > >>
> > > >
> > > >Ewe.  I bet we added that test program _after_ we got 
> > threads working on
> > > >Win32.  That program, and the flags detection configure 
> > checks have made
> > > >threads configuration almost fool-proof, so I don't think we should
> > > >change any of that.
> > > >
> > > >As far as the Win32 API, I am unsure.  Let me see if I can hack up
> > > >thread_test.c to use libpq/pthread-win32.c to see if I can get that
> > > >working.
> > > >
> > > >  
> > > >
> > > 
> > > 
> > > ---------------------------(end of 
> > broadcast)---------------------------
> > > TIP 3: Have you checked our extensive FAQ?
> > > 
> > >                http://www.postgresql.org/docs/faq
> > > 
> > 
> > -- 
> >   Bruce Momjian                        |  http://candle.pha.pa.us
> >   pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
> >   +  If your life is a hard drive,     |  13 Roberts Road
> >   +  Christ can be your backup.        |  Newtown Square, 
> > Pennsylvania 19073
> > 
> > ---------------------------(end of 
> > broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> > 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-odbc by date

Next:From: Dave PageDate: 2005-08-12 21:38:28
Subject: Re: Libpq driver: thread problem
Previous:From: Dave PageDate: 2005-08-12 21:23:58
Subject: Re: Libpq driver: thread problem

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