Thread: Libpq driver: thread problem
Hi Anoop, I found a problem with the driver when playing with Open Link's ODBC Bench program (free download with source - http://www.openlinksw.com/) - the config for my test is attached if you wish to reproduce it. If I run a multithreaded test, and select the 'Use Transactions' option, when the test runs, only one thread actually does any work. The non-libpq driver works as expected. One thing to note, the Windows Port of PostgreSQL has never worked with the --enable-thread-safety option. This has never been a problem for pgAdmin (for example), but may be here. Regards, Dave.
Attachment
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Dave Page > Sent: 14 July 2005 12:06 > To: pgsql-odbc@postgresql.org > Cc: Anoop Kumar > Subject: [ODBC] Libpq driver: thread problem > > One thing to note, the Windows Port of PostgreSQL has never > worked with > the --enable-thread-safety option. This has never been a problem for > pgAdmin (for example), but may be here. After some discussion with Magnus Hagander, that is probably a red herring. He recalls that --enable-thread-safety is needed on platforms that don't have a thread safe API already - windows does as I'm sure you know. Regards, Dave
Dave Page wrote: > > > > -----Original Message----- > > From: pgsql-odbc-owner@postgresql.org > > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Dave Page > > Sent: 14 July 2005 12:06 > > To: pgsql-odbc@postgresql.org > > Cc: Anoop Kumar > > Subject: [ODBC] Libpq driver: thread problem > > > > One thing to note, the Windows Port of PostgreSQL has never > > worked with > > the --enable-thread-safety option. This has never been a problem for > > pgAdmin (for example), but may be here. > > After some discussion with Magnus Hagander, that is probably a red > herring. He recalls that --enable-thread-safety is needed on platforms > that don't have a thread safe API already - windows does as I'm sure you > know. I don't think that is correct --- you do need that flag for libpq to be thread safe. If the thread flag doesn't work on Win32, we need to fix it. I know we applies some patches during 8.0 beta so it _should_ work, and if it doesn't we need to add it to the TODO list or fix it. 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. -- 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
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. -- 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
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 14 July 2005 17:02 > To: Dave Page > Cc: pgsql-odbc@postgresql.org; Anoop Kumar > Subject: Re: [ODBC] Libpq driver: thread problem > > > After some discussion with Magnus Hagander, that is probably a red > > herring. He recalls that --enable-thread-safety is needed > on platforms > > that don't have a thread safe API already - windows does as > I'm sure you > > know. > > I don't think that is correct --- you do need that flag for > libpq to be > thread safe. If the thread flag doesn't work on Win32, we need to fix > it. I know we applies some patches during 8.0 beta so it > _should_ work, > and if it doesn't we need to add it to the TODO list or fix it. > > 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. Regards, Dave
I tested a bit the memory footprint. Test bench: psqlodbclibpq snapshot. 8.0.x PostgreSQL, and it's libpq. Debian Sarge "isql" ODBC query tool. I performed the following kind of query many times: select * from test2 limit 2000000 It has about 5 varchar() columns. The idea is, that redo exactly same query with isql many times and watch the isql memory footprint. I haven't checked the isql code, wether it closes the statement before the next usage. After the first select, the memory footprint was 368 meg. If I iterated the query many times, the memory footprint increased: All memory consumptions are virtual memory usages: 4.5 meg (just connected into the database) 368 meg (after the first SELECT, no mem decrease detected) 502 meg (after the second SELECT,virt increased with 134 meg) 637 meg (virt increased with 135 meg) 772 meg (virt increased with 135 meg) ps showed with one second update the following: at the first SELECT, the memory usage increased steadily during PostgreSQL was also active (inside libpq?). Then it increased steadily before the stdout output began ( string format conversions for every row??) During printing into stdout, the memory footprint kept the same all the time. After the first SELECT, the memory footprints were as follows: Initially the memory footprint was 368 meg. While transferring data from PostgreSQL into libpq, the memory footprint did not increase. Then it increased steadily into 502 meg, so this was during psqlodbc internal processing. Again, when the stdout output began, the memory footprint kept the same in 502 meg. Conclusions: - Somehow, psqlodbc does not free all allocated memory resources after the SELECT has been closed. - I don't know whether the isql does not call PQfree(), or psqlodbc driver's charset conversion data output buffers are not freed. - Memory footprints don't become doubled (500 meg -> 1000 meg with realloc() ), so it seems, that the memory is allocated with small pieces. - If I SELECT 4* 2 meg rows, memory footprint is 770 meg. - If I SELECT 1*8 meg rows, memory footprint is 1400 meg. Twise! Conclusion: half of the used memory is freed with 4*2 meg row fetching. UseDeclareFetch = 1 Fetch = 32 This failed with CONNECT with iodbc: ~$ isql <db> <uid> <pwd> WARNING: there is already a transaction in progress Muistialueen ylitys So with libpq, the "BEGIN" seems to come twice with UseDeclareFetch=1. With UseDeclareFetch=1 almost every SELECT, even on CONNECT, do use DECLARE <name> cursor for SELECT version() like queries. So that's why CONNECT fails with that option. CVS HEAD psqlodbc does the BEGIN correctly. psqlodbclibpq seems to do the UseDeclareFetch BEGIN falsely, with and without libpq. I don't know, wether UseDeclareFetch behaviour is the good way to go. One possibility would be a data filtering mode (FORWARD_ONLY_MODE) with a very small memory footprint on the client side. Of course, if you need to support SELECT results with at least 8 million rows, some (invisible) way to do it would be nice. Implementing FORWARD_ONLY_MODE requires, that libpq would also have a streamlined SELECT mode (without the CURSOR), or then the CURSOR would be needed as it is done now. Other thoughts, but no bugs: I was able to SELECT almost 8 meg rows into memory with isql. It took with Debian Sarge 1400 meg of virtual memory, but isql did not crash. So the memory behaviour seems good, even though I do like about small memory footprints. (I must admit: I had to increase swap space for isql not to crash.) 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. > > >
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. > > >
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
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
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. 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 >
OK, thanks. --------------------------------------------------------------------------- Dave Page wrote: > > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: 12 August 2005 22:25 > > To: Dave Page > > Cc: Marko Ristola; pgsql-odbc@postgresql.org > > Subject: Re: [ODBC] Libpq driver: thread problem > > > > 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? > > Setlocale() doesn't appear to be used in libpq afaics (unless it's used > in some external macro or function I haven't found). > > Besides, the problem being discussed in the thread turned out to be a > logic error in the LIBPQ_Execute function in the driver. Once I tracked > it down, it worked perfectly. > > Regards, Dave. > -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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?
I don't think libpq does any locale manipulation; it shouldn't anyway.
regards, tom lane
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 12 August 2005 22:25 > To: Dave Page > Cc: Marko Ristola; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Libpq driver: thread problem > > 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? Setlocale() doesn't appear to be used in libpq afaics (unless it's used in some external macro or function I haven't found). Besides, the problem being discussed in the thread turned out to be a logic error in the LIBPQ_Execute function in the driver. Once I tracked it down, it worked perfectly. Regards, Dave.