Обсуждение: Solaris ecpg program doesn't work - pulling my hair out!
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
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
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
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!
> 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
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!
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 #
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
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
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
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
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
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