Обсуждение: dyntest.pgc not working in 7.4 ?
Hi everyone,
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.
This is PostgreSQL 7.4 in Sparc Solaris 9.
Any idea ?
Gan
$ psql
Welcome to psql 7.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
Field separator is " ".
A=> select * from lucytest;
c1
----------
record 1
record 2
(2 rows)
A=> \q
$
$ ./lucyDyntest74 lucytest
sqlcode=0
1 Columns
c1 varchar(100)
'record 1'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
'record 2'|
sqlcode=0
....
....
$
$
$ ldd lucyDyntest74
libecpg.so.4 => /platdb/lib/libecpg.so.4
libc.so.1 => /usr/lib/libc.so.1
libpgtypes.so.1 => /platdb/lib/libpgtypes.so.1
libpq.so.3 => /platdb/lib/libpq.so.3
libm.so.1 => /usr/lib/libm.so.1
libdl.so.1 => /usr/lib/libdl.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
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
$
--
+--------------------------------------------------------+
| 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 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!