dyntest.pgc not working in 7.4 ?

On Wed, Dec 10, 2003 at 01:50:39PM -0600, Seum-Lim Gan wrote:

We compiled the dyntest.pgc (in src/interfaces/ecpg/test)
and tried it out but it seems like it is not able to
stop after reading the last record and keep going on
forever. sqlcode return is always 0 and never get to 100
where it is supposed to. The dyntest.pgc has not changed from
7.3.4 to 7.4 and it used to work in 7.3.4.

Do you use any special options to ecpg?

I just tried with CVS HEAD and it runs without a problem. Albeit on an
empty database just showing the system tables.

Anyone else having problems with this test case?

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!

Hi Michael,

This is how we build dyntest:

/platdb/bin/ecpg -I /platdb/include -o dyntest74.c dyntest.pgc
cc -I/platdb/include -R/platdb/lib -L/platdb/lib -lecpg -o
lucyDyntest74 dyntest74.c

The cc here is the Sun Workshop compiler.

Thanks.

Gan

At 10:03 pm +0100 2003/12/10, Michael Meskes wrote:

On Wed, Dec 10, 2003 at 01:50:39PM -0600, Seum-Lim Gan wrote:

We compiled the dyntest.pgc (in src/interfaces/ecpg/test)
and tried it out but it seems like it is not able to
stop after reading the last record and keep going on
forever. sqlcode return is always 0 and never get to 100
where it is supposed to. The dyntest.pgc has not changed from
7.3.4 to 7.4 and it used to work in 7.3.4.

Do you use any special options to ecpg?

I just tried with CVS HEAD and it runs without a problem. Albeit on an
empty database just showing the system tables.

Anyone else having problems with this test case?

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!

-- 
+--------------------------------------------------------+
| Seum-Lim GAN                 email : slgan@lucent.com  |
| Lucent Technologies                                    |
| 2000 N. Naperville Road, 6B-403F  tel : (630)-713-6665 |
| Naperville, IL 60566, USA.        fax : (630)-713-7272 |
|       web : http://inuweb.ih.lucent.com/~slgan         |
+--------------------------------------------------------+

On Wed, Dec 10, 2003 at 03:29:44PM -0600, Seum-Lim Gan wrote:

/platdb/bin/ecpg -I /platdb/include -o dyntest74.c dyntest.pgc
cc -I/platdb/include -R/platdb/lib -L/platdb/lib -lecpg -o
lucyDyntest74 dyntest74.c

This looks like a wrong library. The latest ecpg does need more that
libecpg. It also needs libpgtypes. Since you don't include this i wonder
if you link against an older libecpg.

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!

Hi Michael,

We tried but seems this didn't solve the problem.

Actually the ldd command in the log I attached yesterday
has showed the link to the right libecpgtypes.so and libpg.so.

Adding the -lecpgtypes and -l libpg in build did not change anything.

It looks to us that the sqlca.sqlcode will never be set to non-zero
value when SQL errors, warnings, not_found happen.

Gan

At 4:09 pm +0100 2003/12/11, Michael Meskes wrote:

On Wed, Dec 10, 2003 at 03:29:44PM -0600, Seum-Lim Gan wrote:

/platdb/bin/ecpg -I /platdb/include -o dyntest74.c dyntest.pgc
cc -I/platdb/include -R/platdb/lib -L/platdb/lib -lecpg -o
lucyDyntest74 dyntest74.c

This looks like a wrong library. The latest ecpg does need more that
libecpg. It also needs libpgtypes. Since you don't include this i wonder
if you link against an older libecpg.

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!

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
+--------------------------------------------------------+
| Seum-Lim GAN                 email : slgan@lucent.com  |
| Lucent Technologies                                    |
| 2000 N. Naperville Road, 6B-403F  tel : (630)-713-6665 |
| Naperville, IL 60566, USA.        fax : (630)-713-7272 |
|       web : http://inuweb.ih.lucent.com/~slgan         |
+--------------------------------------------------------+

Hi,

On Thu, Dec 11, 2003 at 04:10:05PM -0600, Seum-Lim Gan wrote:

Hi Michael,

We tried but seems this didn't solve the problem.

Actually the ldd command in the log I attached yesterday
has showed the link to the right libecpgtypes.so and libpg.so.

You misunderstood me. I wasn't talking about libpq but about libpgtypes.
The latest libecpg should depend on libpgtypes. Since yours doesn't I
wonder which on you link to your program.

Could you please tell me which version of libecpg you are using?

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!

Hi Michael,

Looks like the libecpg we are using is 4.0.

Any idea ?

Gan

-rw-r--r-- 1 postgres postgres 245396 Dec 10 21:57 libpq.a
-rwxr-xr-x 1 postgres postgres 210700 Dec 10 21:57 libpq.so.3.1
lrwxrwxrwx 1 postgres postgres 12 Dec 10 21:57 libpq.so.3 ->
libpq.so.3.1
lrwxrwxrwx 1 postgres postgres 12 Dec 10 21:57 libpq.so -> libpq.so.3.1
-rw-r--r-- 1 postgres postgres 126432 Dec 10 21:57 libpgtypes.a
-rwxr-xr-x 1 postgres postgres 112972 Dec 10 21:58 libpgtypes.so.1.0
lrwxrwxrwx 1 postgres postgres 17 Dec 10 21:58 libpgtypes.so.1
-> libpgtypes.so.1.0
lrwxrwxrwx 1 postgres postgres 17 Dec 10 21:58 libpgtypes.so
-> libpgtypes.so.1.0
-rw-r--r-- 1 postgres postgres 110964 Dec 10 21:58 libecpg.a
-rw-r--r-- 1 postgres postgres 20140 Dec 10 21:58 libecpg_compat.a
-rwxr-xr-x 1 postgres postgres 97528 Dec 10 21:58 libecpg.so.4.0
lrwxrwxrwx 1 postgres postgres 14 Dec 10 21:58 libecpg.so.4 ->
libecpg.so.4.0
lrwxrwxrwx 1 postgres postgres 14 Dec 10 21:58 libecpg.so ->
libecpg.so.4.0
-rwxr-xr-x 1 postgres postgres 23876 Dec 10 21:58 libecpg_compat.so.1.0
lrwxrwxrwx 1 postgres postgres 21 Dec 10 21:58
libecpg_compat.so.1 -> libecpg_compat.so.1.0
lrwxrwxrwx 1 postgres postgres 21 Dec 10 21:58
libecpg_compat.so -> libecpg_compat.so.1.0

At 7:33 am +0100 2003/12/12, Michael Meskes wrote:

Hi,

On Thu, Dec 11, 2003 at 04:10:05PM -0600, Seum-Lim Gan wrote:

Hi Michael,

We tried but seems this didn't solve the problem.

Actually the ldd command in the log I attached yesterday
has showed the link to the right libecpgtypes.so and libpg.so.

You misunderstood me. I wasn't talking about libpq but about libpgtypes.
The latest libecpg should depend on libpgtypes. Since yours doesn't I
wonder which on you link to your program.

Could you please tell me which version of libecpg you are using?

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!

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
+--------------------------------------------------------+
| Seum-Lim GAN                 email : slgan@lucent.com  |
| Lucent Technologies                                    |
| 2000 N. Naperville Road, 6B-403F  tel : (630)-713-6665 |
| Naperville, IL 60566, USA.        fax : (630)-713-7272 |
|       web : http://inuweb.ih.lucent.com/~slgan         |
+--------------------------------------------------------+

On Fri, Dec 12, 2003 at 01:07:01AM -0600, Seum-Lim Gan wrote:

Hi Michael,

Looks like the libecpg we are using is 4.0.

Any idea ?

Please run the program against an empty database and the pg_tables table
and see what happens then. Also could you please send me the file "log"
dyntext produces?

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!

On Sat, Dec 20, 2003 at 05:48:41AM +0800, Liang, Guang Yu (Lucy) wrote:

I attach the logs here with empty database and pg_table.
(I assume the empty database means we don't assign
DB any value such as "mm"). The log is big since it

Actually I also meant to use a database with no tables defined other
than the system ones.

Another thing is when I query a non-existing table, there
are Errors in the log, but the the dyntest example didn't stop
either. So it seems to me the sqlca.sqlcode is never set.
I have also tried to print out sqlstate, it's always 00000.

The same seems to happen with NOT FOUND. The log files says "raising
sqlcode 100 in line 57, 'No data found in line 57.'." more than 500
times. :-(

Did you compile with ENABLE_THREAD_SAFETY?

Is there a way for me to get a login into your machine? The code looks
okay to me. At the moment I have no idea what's going on.

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!

Michael,

Yes, the enable-thread-safety is used in configure file.
Is it expected to be there?

I can try an empty database and let you know the result.

For machine login, I'm afraid it will be agains Lucent
Security policy. Maybe we can try to open a Netmeeting
session and share the desktop to see the same window.

If this is feasible, we will have to work out a time. I'm in
Beijing China and the time Zone is GMT+8. We have 8
hours time difference, right? I will be available in the
morning of Dec 31, say 9:00 am. Please let me know
whether it's a good time for you.

Thanks,
Lucy

-----Original Message-----
From: Michael Meskes [mailto:meskes@postgresql.org]
Sent: Saturday, December 27, 2003 4:31 AM
To: Liang, Guang Yu (Lucy)
Cc: Seum-Lim Gan; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] dyntest.pgc not working in 7.4 ?

On Sat, Dec 20, 2003 at 05:48:41AM +0800, Liang, Guang Yu (Lucy) wrote:

I attach the logs here with empty database and pg_table.
(I assume the empty database means we don't assign
DB any value such as "mm"). The log is big since it

Actually I also meant to use a database with no tables defined other
than the system ones.

Another thing is when I query a non-existing table, there
are Errors in the log, but the the dyntest example didn't stop
either. So it seems to me the sqlca.sqlcode is never set.
I have also tried to print out sqlstate, it's always 00000.

The same seems to happen with NOT FOUND. The log files says "raising
sqlcode 100 in line 57, 'No data found in line 57.'." more than 500
times. :-(

Did you compile with ENABLE_THREAD_SAFETY?

Is there a way for me to get a login into your machine? The code looks
okay to me. At the moment I have no idea what's going on.

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!

Michael,

As you indicated, we may change some configurations
to see whether it can help.

The configuration parameters I used are as follows:

/bin/env CC=$MYCC ./configure \
--prefix=/platdb \
--with-pgport=5333 \
--without-readline \
--with-CXX \
--with-perl \
--with-java \
--with-pam \
--enable-syslog \
--enable-thread-safety \
--enable-nls 2>&1 1>>$PGLOG

Any suggestions?

Thanks,
Lucy

-----Original Message-----
From: Liang, Guang Yu (Lucy) [mailto:lucyliang@lucent.com]
Sent: Monday, December 29, 2003 3:10 PM
To: 'Michael Meskes'
Cc: Seum-Lim Gan; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] dyntest.pgc not working in 7.4 ?

Michael,

Yes, the enable-thread-safety is used in configure file.
Is it expected to be there?

I can try an empty database and let you know the result.

For machine login, I'm afraid it will be agains Lucent
Security policy. Maybe we can try to open a Netmeeting
session and share the desktop to see the same window.

If this is feasible, we will have to work out a time. I'm in
Beijing China and the time Zone is GMT+8. We have 8
hours time difference, right? I will be available in the
morning of Dec 31, say 9:00 am. Please let me know
whether it's a good time for you.

Thanks,
Lucy

-----Original Message-----
From: Michael Meskes [mailto:meskes@postgresql.org]
Sent: Saturday, December 27, 2003 4:31 AM
To: Liang, Guang Yu (Lucy)
Cc: Seum-Lim Gan; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] dyntest.pgc not working in 7.4 ?

On Sat, Dec 20, 2003 at 05:48:41AM +0800, Liang, Guang Yu (Lucy) wrote:

I attach the logs here with empty database and pg_table.
(I assume the empty database means we don't assign
DB any value such as "mm"). The log is big since it

Actually I also meant to use a database with no tables defined other
than the system ones.

Another thing is when I query a non-existing table, there
are Errors in the log, but the the dyntest example didn't stop
either. So it seems to me the sqlca.sqlcode is never set.
I have also tried to print out sqlstate, it's always 00000.

The same seems to happen with NOT FOUND. The log files says "raising
sqlcode 100 in line 57, 'No data found in line 57.'." more than 500
times. :-(

Did you compile with ENABLE_THREAD_SAFETY?

Is there a way for me to get a login into your machine? The code looks
okay to me. At the moment I have no idea what's going on.

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!

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Mon, Dec 29, 2003 at 03:10:12PM +0800, Liang, Guang Yu (Lucy) wrote:

Yes, the enable-thread-safety is used in configure file.
Is it expected to be there?

Could you please try to configure without threading? I'd just like to
remove all components not neccessary to see if the problem still arises.

I can try an empty database and let you know the result.

ok.

For machine login, I'm afraid it will be agains Lucent
Security policy. Maybe we can try to open a Netmeeting
session and share the desktop to see the same window.

Actually I'm afraid that won't be enough, as I can send you all things
to test via email as well. The problem is that this has such a long
turnaround. If I could access the machine, or another one with this bug,
myself, I could test debug the whole stuff.

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!

Hi, Michael,

When configure without enable-thread-safety, the example
works perfect. Thank you for the great help!

I still have a few questions:
1. Is it a known bug or does it only happens in my case?
2. how will it affect PostgreSQL if we don't use this
parameter?

Thanks,
Lucy

-----Original Message-----
From: Michael Meskes [mailto:meskes@postgresql.org]
Sent: Tuesday, December 30, 2003 9:12 PM
To: Liang, Guang Yu (Lucy)
Cc: 'Michael Meskes'; Seum-Lim Gan; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] dyntest.pgc not working in 7.4 ?

On Mon, Dec 29, 2003 at 03:10:12PM +0800, Liang, Guang Yu (Lucy) wrote:

Yes, the enable-thread-safety is used in configure file.
Is it expected to be there?

Could you please try to configure without threading? I'd just like to
remove all components not neccessary to see if the problem still arises.

I can try an empty database and let you know the result.

ok.

For machine login, I'm afraid it will be agains Lucent
Security policy. Maybe we can try to open a Netmeeting
session and share the desktop to see the same window.

Actually I'm afraid that won't be enough, as I can send you all things
to test via email as well. The problem is that this has such a long
turnaround. If I could access the machine, or another one with this bug,
myself, I could test debug the whole stuff.

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!

Hi Michael,

Are you able to figure out why the thread-safety flag would
trigger this ecpg failure with dyntest.pgc ?

Thanks.

Gan

At 3:40 pm +0800 2004/1/5, Liang, Guang Yu (Lucy) wrote:

Hi, Michael,

When configure without enable-thread-safety, the example
works perfect. Thank you for the great help!

I still have a few questions:
1. Is it a known bug or does it only happens in my case?
2. how will it affect PostgreSQL if we don't use this
parameter?

Thanks,
Lucy

-----Original Message-----
From: Michael Meskes [mailto:meskes@postgresql.org]
Sent: Tuesday, December 30, 2003 9:12 PM
To: Liang, Guang Yu (Lucy)
Cc: 'Michael Meskes'; Seum-Lim Gan; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] dyntest.pgc not working in 7.4 ?

On Mon, Dec 29, 2003 at 03:10:12PM +0800, Liang, Guang Yu (Lucy) wrote:

Yes, the enable-thread-safety is used in configure file.
Is it expected to be there?

Could you please try to configure without threading? I'd just like to
remove all components not neccessary to see if the problem still arises.

I can try an empty database and let you know the result.

ok.

For machine login, I'm afraid it will be agains Lucent
Security policy. Maybe we can try to open a Netmeeting
session and share the desktop to see the same window.

Actually I'm afraid that won't be enough, as I can send you all things
to test via email as well. The problem is that this has such a long
turnaround. If I could access the machine, or another one with this bug,
myself, I could test debug the whole stuff.

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!

-- 
+--------------------------------------------------------+
| Seum-Lim GAN                 email : slgan@lucent.com  |
| Lucent Technologies                                    |
| 2000 N. Naperville Road, 6B-403F  tel : (630)-713-6665 |
| Naperville, IL 60566, USA.        fax : (630)-713-7272 |
|       web : http://inuweb.ih.lucent.com/~slgan         |
+--------------------------------------------------------+

Hi Michael and all,

After working with Bruce last night about the
src/template/solaris file, there is a new version
of the file to be used for compiling with
--enable-thread-safety.

This version compiled without errors this time.

This version also resolved the issue with dyntest.pgc
failing in 7.4.x.

I have tested the new compile and ran both dyntest and dyntest2.
Both ran without problem.

Just for quick reference the new template/solaris file
from Bruce looks like this:
============
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

THREAD_SUPPORT=yes
NEED_REENTRANT_FUNCS=yes # 5.6 2003-09-13
if test "$GCC" = yes
then THREAD_LIBS="-pthread"
else THREAD_CPPFLAGS="-mt"
THREAD_LIBS="-lpthread"
fi
============

Both Lucy and I would like to thank everyone who helped
one way or the other !

Thanks.

Gan
-- 
+--------------------------------------------------------+
| Seum-Lim GAN                 email : slgan@lucent.com  |
| Lucent Technologies                                    |
| 2000 N. Naperville Road, 6B-403F  tel : (630)-713-6665 |
| Naperville, IL 60566, USA.        fax : (630)-713-7272 |
|       web : http://inuweb.ih.lucent.com/~slgan         |
+--------------------------------------------------------+

On Thu, Jan 08, 2004 at 12:05:11PM -0600, Seum-Lim Gan wrote:

After working with Bruce last night about the
src/template/solaris file, there is a new version
of the file to be used for compiling with
--enable-thread-safety.
...
I have tested the new compile and ran both dyntest and dyntest2.
Both ran without problem.

Glad to hear that.

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!