Re: Libpq driver: thread problem - Mailing list 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@postgresql.org
> > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Bruce Momjian
> > Sent: 12 August 2005 22:12
> > To: Marko Ristola
> > Cc: pgsql-odbc@postgresql.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@candle.pha.pa.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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073