Solaris ecpg program doesn't work - pulling my hair out!

Started by Wesabout 22 years ago13 messagesgeneral

wespvp@syntegra.com

about 22 years ago

I have an ecpg program that runs perfectly on Linux (PostgreSQL 7.4.1). I
recompile it on Solaris and when I try to run it the results are total
gibberish. When I connect:

EXEC SQL WHENEVER SQLERROR GOTO sql_error;
EXEC SQL CONNECT TO :dbTarget USER :user USING :pw;

Where dbTarget = mydb@host.my.domain
user = xxxuser
pw = xxxpassword

The GOTO is not taken and sqlca.sqlcode is set to 0 (no error).

Similarly, when I try to fetch records, either using SELECT or with a
DECLARE CURSOR/FETCH, I get no records and sqlcl.sqlcode is zero (no error).
Since I get no record, but no error is detected, the variables are garbage
and the program SEGV's trying to manipulate the variables.

The above problems occur whether I use valid information for host/user/pw,
or put in totally bogus values. Again, the program works perfectly on
Linux.

Psql works, and handles errors properly. Yet here, nothing works but no
error codes are set.

Any ideas what could be going on? Is ecpg broken on Solaris? Since psql
works, it would seem that the build is valid.

Wes

Bruce Momjian

bruce@momjian.us

about 22 years ago

In reply to: Wes (#1)

Re: Solaris ecpg program doesn't work - pulling my hair out!

If I had to take a guess, there is something wrong with the ecpg program
and the error is masked on Linux, but is visible on Solaris. I would
break the program down into small parts and test to see where there
error starts.

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

wespvp@syntegra.com wrote:

I have an ecpg program that runs perfectly on Linux (PostgreSQL 7.4.1). I
recompile it on Solaris and when I try to run it the results are total
gibberish. When I connect:

EXEC SQL WHENEVER SQLERROR GOTO sql_error;
EXEC SQL CONNECT TO :dbTarget USER :user USING :pw;

Where dbTarget = mydb@host.my.domain
user = xxxuser
pw = xxxpassword

The GOTO is not taken and sqlca.sqlcode is set to 0 (no error).

Similarly, when I try to fetch records, either using SELECT or with a
DECLARE CURSOR/FETCH, I get no records and sqlcl.sqlcode is zero (no error).
Since I get no record, but no error is detected, the variables are garbage
and the program SEGV's trying to manipulate the variables.

The above problems occur whether I use valid information for host/user/pw,
or put in totally bogus values. Again, the program works perfectly on
Linux.

Psql works, and handles errors properly. Yet here, nothing works but no
error codes are set.

Any ideas what could be going on? Is ecpg broken on Solaris? Since psql
works, it would seem that the build is valid.

Wes

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

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

Wes

wespvp@syntegra.com

about 22 years ago

In reply to: Bruce Momjian (#2)

Re: Solaris ecpg program doesn't work - pulling my hair

On 3/23/04 8:28 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

If I had to take a guess, there is something wrong with the ecpg program
and the error is masked on Linux, but is visible on Solaris. I would
break the program down into small parts and test to see where there
error starts.

I posted a follow up, including a small sample program. The ecpg C code
output is identical on both Linux and Solaris. The problem exists all the
time - the error code is *never* set (at least never that I've seen). Sqlca
is always the same regardless of success or failure of the operation. The
reason it appeared valid operations didn't work is I was searching for the
wrong record, and since there's no error code set...

Wes

Michael Meskes

meskes@postgresql.org

about 22 years ago

In reply to: Wes (#1)

Re: Solaris ecpg program doesn't work - pulling my hair out!

On Tue, Mar 23, 2004 at 05:25:22PM -0600, wespvp@syntegra.com wrote:

I have an ecpg program that runs perfectly on Linux (PostgreSQL 7.4.1). I
recompile it on Solaris and when I try to run it the results are total
...
Any ideas what could be going on? Is ecpg broken on Solaris? Since psql
works, it would seem that the build is valid.

We had this in the past. I'm not sure and would have to search the
archives but I vaguely remember that this has been a threading bug in
the Solaris version. Could you please try using 7.4.2 or cvs head where
this should be fixed. Alternatively you could try with threadding
disabled.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Wes

wespvp@syntegra.com

about 22 years ago

In reply to: Michael Meskes (#4)

Re: Solaris ecpg program doesn't work - pulling my hair

We had this in the past. I'm not sure and would have to search the
archives but I vaguely remember that this has been a threading bug in
the Solaris version. Could you please try using 7.4.2 or cvs head where
this should be fixed. Alternatively you could try with threadding
disabled.

I verified last night that this problem also occurs with 7.4.2. I did some
more extensive testing on the solution in my previous follow-up email. That
is definitely the problem - configure is setting "-pthread" instead of
"-lpthread" in config.status. After manually correcting this in
config.status, everything works properly.

I don't know enough about configure to know how to fix configure. It is
properly setting -lpthread on linux.

It's also not clear why the symptoms occur since the build does not abort
with an unsatisfied external. It must be picking up the pthread externals
from soemwhere else? The only difference I can se in the ldd's is the order
of the libraries. An ldd of ecpglib shows:

Good:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -lpthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

Bad:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -pthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
gcc: unrecognized option `-pthread'
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% !ldd
ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

I realize it isn't entirely meaningful without the source code to know
exactly where I put the print statements, but here is my debug output
running the previously enclosed test program. You can see that it is
allocating a new sqlca structure when it shouldn't be.

Good:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGINIT: address of sqlca = 0x23b98
In ECPGconnect
ECPGconnect: address of sqlca = 0x23b98
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
In error.c - code = -402
ECPGraise: address of sqlca = 0x23b98
After ECPGraise, sqlca->sqlcode = -402
ECPGconnect: address of sqlca = 0x23b98
Before return false, sqlca->sqlcode = -402
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
Connect failure: -402

Bad:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23900
ECPGget_sqlca: before return: address of sqlca = 0x23900
ECPGINIT: address of sqlca = 0x23900
In ECPGconnect
ECPGconnect: address of sqlca = 0x23900
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23900
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x251b0
ECPGget_sqlca: before return: address of sqlca = 0x251b0
In error.c - code = -402
ECPGraise: address of sqlca = 0x251b0
After ECPGraise, sqlca->sqlcode = 0
ECPGconnect: address of sqlca = 0x23900
Before return false, sqlca->sqlcode = 0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25248
ECPGget_sqlca: before return: address of sqlca = 0x25248
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: before return: address of sqlca = 0x252e0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25378
ECPGget_sqlca: before return: address of sqlca = 0x25378
In error.c - code = -220
ECPGraise: address of sqlca = 0x25378
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25410
ECPGget_sqlca: before return: address of sqlca = 0x25410
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x254a8
ECPGget_sqlca: before return: address of sqlca = 0x254a8
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25540
ECPGget_sqlca: before return: address of sqlca = 0x25540
SELECT error code: 0
systemNum = -4261248

I just got this in response to a post to pgsql-general on a different
Solaris problem. This sounds like the same problem as I'm seeing. I've
sent him my solution. Hopefully it will solve his symptoms also.

One other problem I am looking into (and why I tried to compile with
thread safety in the first place) is that this somehow did not turn on
-D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
the threadsafe definition of errno, leading to serious communication
trouble in the end (pqReadData() failing with ENOENT while the real
error is a harmless EAGAIN from a nonblocking recv()).

Jan

Wes

Michael Meskes

meskes@postgresql.org

about 22 years ago

In reply to: Wes (#5)

Re: Solaris ecpg program doesn't work - pulling my hair out!

On Thu, Mar 25, 2004 at 08:07:04AM -0600, wespvp@syntegra.com wrote:

I verified last night that this problem also occurs with 7.4.2. I did some

Hmm, I know some fix was discussed. But maybe it just went into HEAD.

Michael

--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Jan Wieck

JanWieck@Yahoo.com

about 22 years ago

In reply to: Wes (#5)

Re: Solaris ecpg program doesn't work - pulling my hair

wespvp@syntegra.com wrote:

We had this in the past. I'm not sure and would have to search the
archives but I vaguely remember that this has been a threading bug in
the Solaris version. Could you please try using 7.4.2 or cvs head where
this should be fixed. Alternatively you could try with threadding
disabled.

I verified last night that this problem also occurs with 7.4.2. I did some
more extensive testing on the solution in my previous follow-up email. That
is definitely the problem - configure is setting "-pthread" instead of
"-lpthread" in config.status. After manually correcting this in
config.status, everything works properly.

As stated before, this is not true. If you don't compile with
-D_REENTRANT, the /usr/include/errno.h declared errno as

extern int errno;

instead of the thread safe

extern int *___errno();
#define errno *(___errno())

At least it does so here on Solaris 8. That leads to libpq using the
global errno variable, which might or might not be the one where "your"
error is in a multithreaded program. I mailed the correct solution as a
follow up to the other thread earlier today as a patch against 7.4.2.

I don't know enough about configure to know how to fix configure. It is
properly setting -lpthread on linux.

Just linking against the right libraries does not do it here. Solaris is
not Linux.

Jan

It's also not clear why the symptoms occur since the build does not abort
with an unsatisfied external. It must be picking up the pthread externals
from soemwhere else? The only difference I can se in the ldd's is the order
of the libraries. An ldd of ecpglib shows:

Good:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -lpthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

Bad:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -pthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
gcc: unrecognized option `-pthread'
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% !ldd
ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

I realize it isn't entirely meaningful without the source code to know
exactly where I put the print statements, but here is my debug output
running the previously enclosed test program. You can see that it is
allocating a new sqlca structure when it shouldn't be.

Good:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGINIT: address of sqlca = 0x23b98
In ECPGconnect
ECPGconnect: address of sqlca = 0x23b98
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
In error.c - code = -402
ECPGraise: address of sqlca = 0x23b98
After ECPGraise, sqlca->sqlcode = -402
ECPGconnect: address of sqlca = 0x23b98
Before return false, sqlca->sqlcode = -402
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
Connect failure: -402

Bad:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23900
ECPGget_sqlca: before return: address of sqlca = 0x23900
ECPGINIT: address of sqlca = 0x23900
In ECPGconnect
ECPGconnect: address of sqlca = 0x23900
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23900
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x251b0
ECPGget_sqlca: before return: address of sqlca = 0x251b0
In error.c - code = -402
ECPGraise: address of sqlca = 0x251b0
After ECPGraise, sqlca->sqlcode = 0
ECPGconnect: address of sqlca = 0x23900
Before return false, sqlca->sqlcode = 0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25248
ECPGget_sqlca: before return: address of sqlca = 0x25248
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: before return: address of sqlca = 0x252e0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25378
ECPGget_sqlca: before return: address of sqlca = 0x25378
In error.c - code = -220
ECPGraise: address of sqlca = 0x25378
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25410
ECPGget_sqlca: before return: address of sqlca = 0x25410
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x254a8
ECPGget_sqlca: before return: address of sqlca = 0x254a8
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25540
ECPGget_sqlca: before return: address of sqlca = 0x25540
SELECT error code: 0
systemNum = -4261248

I just got this in response to a post to pgsql-general on a different
Solaris problem. This sounds like the same problem as I'm seeing. I've
sent him my solution. Hopefully it will solve his symptoms also.

One other problem I am looking into (and why I tried to compile with
thread safety in the first place) is that this somehow did not turn on
-D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
the threadsafe definition of errno, leading to serious communication
trouble in the end (pqReadData() failing with ENOENT while the real
error is a harmless EAGAIN from a nonblocking recv()).

Jan

Wes

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Bruce Momjian

bruce@momjian.us

about 22 years ago

In reply to: Michael Meskes (#6)

Re: Solaris ecpg program doesn't work - pulling my hair out!

Michael Meskes wrote:

On Thu, Mar 25, 2004 at 08:07:04AM -0600, wespvp@syntegra.com wrote:

I verified last night that this problem also occurs with 7.4.2. I did some

Hmm, I know some fix was discussed. But maybe it just went into HEAD.

Yes, please download CVS HEAD or the nightly snapshots via ftp and test
it. Sorry. Thanks.

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

Wes Palmer

Wesley.R.Palmer@syntegra.com

about 22 years ago

In reply to: Jan Wieck (#7)

Re: Solaris ecpg program doesn't work - pulling my hair

On 3/25/04 1:42 PM, "Jan Wieck" <JanWieck@yahoo.com> wrote:

As stated before, this is not true. If you don't compile with
-D_REENTRANT, the /usr/include/errno.h declared errno as

extern int errno;

instead of the thread safe

extern int *___errno();
#define errno *(___errno())

At least it does so here on Solaris 8. That leads to libpq using the
global errno variable, which might or might not be the one where "your"
error is in a multithreaded program. I mailed the correct solution as a
follow up to the other thread earlier today as a patch against 7.4.2.

The change I made most definitely corrects the problem I was seeing where I
was getting no error handling in ecpg problems. I could correct my problem
by rebuilding only libecpg*. Sounds like the problem you found is related,
but not exactly the same as what I found.

Are you referring to the attachment threadsafe-libpq-742-diff.gz?
Unfortunately, I'm committed to 7.4.1 right now, so have to make it work
properly. threadsafe-libpq-742-diff.gz is rather large, and I don't think I
want to fit it into the 7.4.1 source. I can't just download the latest CVS
source. What can I change in my build to get it to properly specify
-D_REENTRANT? Sorry, I'm not a configure wiz...

I don't know enough about configure to know how to fix configure. It is
properly setting -lpthread on linux.

Just linking against the right libraries does not do it here. Solaris is
not Linux.

The problem I found in config.status is definitely a bug. As released, the
build specifies '-pthread' on the GCC command line, which is obviously not a
valid GCC parameter. -lpthread needs to be specified, not -pthread.

Wes

#10

Bruce Momjian

bruce@momjian.us

about 22 years ago

In reply to: Wes (#5)

Re: Solaris ecpg program doesn't work - pulling my hair

Yep. As I said in a previous email, this is fixed in current CVS and
will be fixed in 7.4.3. Here is the template/solaris file you need:

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

if test "$GCC" != yes ; then
CC="$CC -Xa" # relaxed ISO C mode
CFLAGS="-O -v" # -v is like gcc -Wall
fi

# Pick right test-and-set (TAS) code.
case $host in
sparc-*-solaris*) need_tas=yes; tas_file=solaris_sparc.s ;;
i?86-*-solaris*) need_tas=yes; tas_file=solaris_i386.s ;;
esac

# tools/thread/thread_test must be run
# -D_POSIX_PTHREAD_SEMANTICS enables 5-arg getpwuid_r, among other things
if test "$GCC" = yes
then THREAD_CPPFLAGS="-D_POSIX_PTHREAD_SEMANTICS"
THREAD_LIBS="-pthread"
else THREAD_CPPFLAGS="-mt -D_POSIX_PTHREAD_SEMANTICS"
THREAD_LIBS="-lpthread"
fi

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

wespvp@syntegra.com wrote:

We had this in the past. I'm not sure and would have to search the
archives but I vaguely remember that this has been a threading bug in
the Solaris version. Could you please try using 7.4.2 or cvs head where
this should be fixed. Alternatively you could try with threadding
disabled.

I verified last night that this problem also occurs with 7.4.2. I did some
more extensive testing on the solution in my previous follow-up email. That
is definitely the problem - configure is setting "-pthread" instead of
"-lpthread" in config.status. After manually correcting this in
config.status, everything works properly.

I don't know enough about configure to know how to fix configure. It is
properly setting -lpthread on linux.

It's also not clear why the symptoms occur since the build does not abort
with an unsatisfied external. It must be picking up the pthread externals
from soemwhere else? The only difference I can se in the ldd's is the order
of the libraries. An ldd of ecpglib shows:

Good:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -lpthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

Bad:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -pthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
gcc: unrecognized option `-pthread'
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% !ldd
ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

I realize it isn't entirely meaningful without the source code to know
exactly where I put the print statements, but here is my debug output
running the previously enclosed test program. You can see that it is
allocating a new sqlca structure when it shouldn't be.

Good:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGINIT: address of sqlca = 0x23b98
In ECPGconnect
ECPGconnect: address of sqlca = 0x23b98
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
In error.c - code = -402
ECPGraise: address of sqlca = 0x23b98
After ECPGraise, sqlca->sqlcode = -402
ECPGconnect: address of sqlca = 0x23b98
Before return false, sqlca->sqlcode = -402
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
Connect failure: -402

Bad:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23900
ECPGget_sqlca: before return: address of sqlca = 0x23900
ECPGINIT: address of sqlca = 0x23900
In ECPGconnect
ECPGconnect: address of sqlca = 0x23900
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23900
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x251b0
ECPGget_sqlca: before return: address of sqlca = 0x251b0
In error.c - code = -402
ECPGraise: address of sqlca = 0x251b0
After ECPGraise, sqlca->sqlcode = 0
ECPGconnect: address of sqlca = 0x23900
Before return false, sqlca->sqlcode = 0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25248
ECPGget_sqlca: before return: address of sqlca = 0x25248
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: before return: address of sqlca = 0x252e0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25378
ECPGget_sqlca: before return: address of sqlca = 0x25378
In error.c - code = -220
ECPGraise: address of sqlca = 0x25378
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25410
ECPGget_sqlca: before return: address of sqlca = 0x25410
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x254a8
ECPGget_sqlca: before return: address of sqlca = 0x254a8
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25540
ECPGget_sqlca: before return: address of sqlca = 0x25540
SELECT error code: 0
systemNum = -4261248

I just got this in response to a post to pgsql-general on a different
Solaris problem. This sounds like the same problem as I'm seeing. I've
sent him my solution. Hopefully it will solve his symptoms also.

One other problem I am looking into (and why I tried to compile with
thread safety in the first place) is that this somehow did not turn on
-D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
the threadsafe definition of errno, leading to serious communication
trouble in the end (pqReadData() failing with ENOENT while the real
error is a harmless EAGAIN from a nonblocking recv()).

Jan

Wes

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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

#11

Ryan Riehle

rkr@buildways.com

about 22 years ago

In reply to: Wes Palmer (#9)

No title

Trying to upgrade to Apache 2.0.49 and getting compile errors related to
mod_auth_pgsql:

make[1]: Entering directory `/usr/src/httpd-2.0.49'
/usr/src/httpd-2.0.49/srclib/apr/libtool --silent --mode=link gcc -pthread
-I/
=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-DAP_HAVE_DESIGNATED_INITIALIZER
I. -I/usr/src/httpd-2.0.49/os/unix
-I/usr/src/httpd-2.0.49/server/mpm/prefork -I
.49/modules/proxy -I/usr/src/httpd-2.0.49/include
-I/usr/src/httpd-2.0.49/module
-o httpd modules.lo modules/aaa/mod_access.la modules/aaa/mod_auth.la
modules
s/metadata/mod_env.la modules/metadata/mod_mime_magic.la
modules/metadata/mod_ex
_setenvif.la modules/ssl/mod_ssl.la modules/http/mod_http.la
modules/http/mod_mi
a modules/generators/mod_autoindex.la modules/generators/mod_asis.la
modules/gen
ers/mod_dir.la modules/mappers/mod_imap.la modules/mappers/mod_actions.la
module
ork/libprefork.la server/libmain.la os/unix/libos.la -lssl -lcrypto
/usr/src/htt
ldb-4.0 -lexpat -liconv /usr/src/httpd-2.0.49/srclib/apr/libapr-0.la -lrt
-lm -l
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x470): In
function
: undefined reference to `PQsetdbLogin'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x482): In
function
: undefined reference to `PQstatus'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x49a): In
function
: undefined reference to `PQreset'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x4aa): In
function
: undefined reference to `PQerrorMessage'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x4d2): In
function
: undefined reference to `PQstatus'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x4e6): In
function
: undefined reference to `PQerrorMessage'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x51d): In
function
: undefined reference to `PQexec'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x53c): In
function
: undefined reference to `PQerrorMessage'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x56e): In
function
: undefined reference to `PQresultStatus'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x580): In
function
: undefined reference to `PQclear'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x59a): In
function
: undefined reference to `PQresultStatus'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x5b5): In
function
: undefined reference to `PQerrorMessage'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x5db): In
function
: undefined reference to `PQclear'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x5f5): In
function
: undefined reference to `PQntuples'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x610): In
function
: undefined reference to `PQgetvalue'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x629): In
function
: undefined reference to `PQerrorMessage'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x64f): In
function
: undefined reference to `PQclear'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x6ad): In
function
: undefined reference to `PQclear'
modules/aaa/.libs/mod_auth_pgsql.al(mod_auth_pgsql.lo)(.text+0x6d5): In
function
: undefined reference to `PQclear'
collect2: ld returned 1 exit status
make[1]: *** [httpd] Error 1
make[1]: Leaving directory `/usr/src/httpd-2.0.49'
make: *** [all-recursive] Error 1

It still compiles fine with apache 2.0.48... I must be missing something,
because I don't see others having similar problems... My configure command
is as follows:

CFLAGS="-I/usr/kerberos/include -DSECURITY_HOLE_PASS_AUTHORIZATION"
./configure --prefix=/usr/apache2 --datadir=/www --enable-auth-digest
--enable-mime-magic --enable-expires --enable-headers --enable-usertrack
--enable-static-rotatelogs --enable-http --enable-dav --enable-dav-fs
-enable-cgi --enable-so --enable-ssl
--with-module=aaa:../mod_auth_pgsql-2.0.1/mod_auth_pgsql.c

#12

Bruce Momjian

bruce@momjian.us

almost 22 years ago

In reply to: Jan Wieck (#7)

Re: Solaris ecpg program doesn't work - pulling my hair

Jan, is this fixed in current CVS and 7.4.X CVS?

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

Jan Wieck wrote:

wespvp@syntegra.com wrote:

We had this in the past. I'm not sure and would have to search the
archives but I vaguely remember that this has been a threading bug in
the Solaris version. Could you please try using 7.4.2 or cvs head where
this should be fixed. Alternatively you could try with threadding
disabled.

I verified last night that this problem also occurs with 7.4.2. I did some
more extensive testing on the solution in my previous follow-up email. That
is definitely the problem - configure is setting "-pthread" instead of
"-lpthread" in config.status. After manually correcting this in
config.status, everything works properly.

As stated before, this is not true. If you don't compile with
-D_REENTRANT, the /usr/include/errno.h declared errno as

extern int errno;

instead of the thread safe

extern int *___errno();
#define errno *(___errno())

At least it does so here on Solaris 8. That leads to libpq using the
global errno variable, which might or might not be the one where "your"
error is in a multithreaded program. I mailed the correct solution as a
follow up to the other thread earlier today as a patch against 7.4.2.

I don't know enough about configure to know how to fix configure. It is
properly setting -lpthread on linux.

Just linking against the right libraries does not do it here. Solaris is
not Linux.

Jan

It's also not clear why the symptoms occur since the build does not abort
with an unsatisfied external. It must be picking up the pthread externals
from soemwhere else? The only difference I can se in the ldd's is the order
of the libraries. An ldd of ecpglib shows:

Good:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -lpthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

Bad:

gcc -shared -h libecpg.so.4 execute.o typename.o descriptor.o data.o error.o
prepare.o memory.o connect.o misc.o -L../../../../src/port
-L/mhinteg/trees/4/sun32_fixes/ported/openssl -L../pgtypeslib -lpgtypes
-L../../../../src/interfaces/libpq -lpq -lssl -lcrypto -lm -pthread
-R/home/wrp/local/pgsql.7.4.2/lib -o libecpg.so.4.1
gcc: unrecognized option `-pthread'
rm -f libecpg.so.4
ln -s libecpg.so.4.1 libecpg.so.4
rm -f libecpg.so
ln -s libecpg.so.4.1 libecpg.so

% !ldd
ldd libecpg.so
libpgtypes.so.1 =>
/home/wrp/local/pgsql.7.4.2/lib/libpgtypes.so.1
libpq.so.3 => /home/wrp/local/pgsql.7.4.2/lib/libpq.so.3
libssl.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/mhinteg/trees/4/sun32_fixes/ported/openssl/libcrypto.so.0.9.7
libm.so.1 => /usr/lib/libm.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

I realize it isn't entirely meaningful without the source code to know
exactly where I put the print statements, but here is my debug output
running the previously enclosed test program. You can see that it is
allocating a new sqlca structure when it shouldn't be.

Good:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGINIT: address of sqlca = 0x23b98
In ECPGconnect
ECPGconnect: address of sqlca = 0x23b98
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
In error.c - code = -402
ECPGraise: address of sqlca = 0x23b98
After ECPGraise, sqlca->sqlcode = -402
ECPGconnect: address of sqlca = 0x23b98
Before return false, sqlca->sqlcode = -402
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x23b98
ECPGget_sqlca: before return: address of sqlca = 0x23b98
Connect failure: -402

Bad:

% ./testit
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x23900
ECPGget_sqlca: before return: address of sqlca = 0x23900
ECPGINIT: address of sqlca = 0x23900
In ECPGconnect
ECPGconnect: address of sqlca = 0x23900
Before connection check
bad connection
ECPGconnect: address of sqlca = 0x23900
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x251b0
ECPGget_sqlca: before return: address of sqlca = 0x251b0
In error.c - code = -402
ECPGraise: address of sqlca = 0x251b0
After ECPGraise, sqlca->sqlcode = 0
ECPGconnect: address of sqlca = 0x23900
Before return false, sqlca->sqlcode = 0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25248
ECPGget_sqlca: before return: address of sqlca = 0x25248
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: before return: address of sqlca = 0x252e0
ECPGINIT: address of sqlca = 0x252e0
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25378
ECPGget_sqlca: before return: address of sqlca = 0x25378
In error.c - code = -220
ECPGraise: address of sqlca = 0x25378
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25410
ECPGget_sqlca: before return: address of sqlca = 0x25410
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x254a8
ECPGget_sqlca: before return: address of sqlca = 0x254a8
ECPGget_sqlca: after pthread_getspecific: address of sqlca = 0x0
ECPGINIT: address of sqlca = 0x25540
ECPGget_sqlca: before return: address of sqlca = 0x25540
SELECT error code: 0
systemNum = -4261248

I just got this in response to a post to pgsql-general on a different
Solaris problem. This sounds like the same problem as I'm seeing. I've
sent him my solution. Hopefully it will solve his symptoms also.

One other problem I am looking into (and why I tried to compile with
thread safety in the first place) is that this somehow did not turn on
-D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not using
the threadsafe definition of errno, leading to serious communication
trouble in the end (pqReadData() failing with ENOENT while the real
error is a harmless EAGAIN from a nonblocking recv()).

Jan

Wes

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

---------------------------(end of broadcast)---------------------------
TIP 4: 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

#13

Bruce Momjian

bruce@momjian.us

almost 22 years ago

In reply to: Wes (#3)

Re: Solaris ecpg program doesn't work - pulling my hair out!

This will be fixed on Solaris in PostgreSQL release 7.4.3.

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

Wes Palmer wrote:

On 3/23/04 8:28 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

If I had to take a guess, there is something wrong with the ecpg program
and the error is masked on Linux, but is visible on Solaris. I would
break the program down into small parts and test to see where there
error starts.

I posted a follow up, including a small sample program. The ecpg C code
output is identical on both Linux and Solaris. The problem exists all the
time - the error code is *never* set (at least never that I've seen). Sqlca
is always the same regardless of success or failure of the operation. The
reason it appeared valid operations didn't work is I was searching for the
wrong record, and since there's no error code set...

Wes

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