Thread: Libpq driver: thread problem

Libpq driver: thread problem

From
"Dave Page"
Date:
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

Re: Libpq driver: thread problem

From
"Dave Page"
Date:

> -----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

Re: Libpq driver: thread problem

From
Bruce Momjian
Date:
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

Re: Libpq driver: thread problem

From
Bruce Momjian
Date:
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

Re: Libpq driver: thread problem

From
"Dave Page"
Date:

> -----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

Re: Libpq driver: thread problem

From
Marko Ristola
Date:

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.
>
>
>


Re: Libpq driver: thread problem

From
Marko Ristola
Date:
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.
>
>
>


Re: Libpq driver: thread problem

From
Bruce Momjian
Date:
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

Re: Libpq driver: thread problem

From
Bruce Momjian
Date:
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

Re: Libpq driver: thread problem

From
"Dave Page"
Date:
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
>

Re: Libpq driver: thread problem

From
Bruce Momjian
Date:
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

Re: Libpq driver: thread problem

From
Tom Lane
Date:
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

Re: Libpq driver: thread problem

From
"Dave Page"
Date:

> -----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.