Re: [HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
On Mon, 4 Jun 2007, Kris Jurka wrote:
On Mon, 4 Jun 2007, Andrew Dunstan wrote:
turnip_moth is also a Solaris 9 box and doesn't seem have the same issue.
Kris, is there anything unusual installed on the box that would make it
behave like this?
Not sure what's going on here. I did a manual run of the ecpg tests and it
completed normally. This machine is quite out of date and it has a large mix
of GNU tools with the solaris ones. Since turnip_moth is maintained by Sun I
would expect it to be up to date on patches and have few non-Sun tools
installed. So it could be using a different interpreter or it could be using
a broken tool for which a patch has been released. I'll try doing a run with
the buildfarm client later today to try and reproduce this.
Running ecpg's pg_regress script with -x yields:
+ cp connect/test2.c results/connect-test2.c
+ connect/test2
+ mv results/connect-test2.c results/connect-test2.c.tmp
+ cat results/connect-test2.c.tmp
+ sed -e s,^\(#line [0-9]*\) .*/\([^/]*\),\1 \2,
+ rm results/connect-test2.c.tmp
+ [ yes = yes ]
./pg_regress: bad substitution
So it looks like it's bailing on this line:
if [ $enable_threading = yes ] [ ${i%%/*} = thread ]; then
and it doesn't like the ${i%%/*} construct. Still not sure why it happens
some places and not others.
Kris Jurka
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
AFAICS, Peter's recent incomplete updating of error message wording should have broken every last man jack of 'em. And yet there's still some green to be seen. I think we are looking at problems in the ecpg test scaffolding. For instance, dragonfly claims a green build, but http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dragonflydt=2007-06-04%20043001stg=ecpg-check shows this interesting trace: == running regression test queries== /export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test/./tmp_check/install//export/home/pgfarm/gcc/HEAD/inst/bin/createuser -R -S -D -q regressuser1 /export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test/./tmp_check/install//export/home/pgfarm/gcc/HEAD/inst/bin/createuser -R -S -D -q connectuser /export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test/./tmp_check/install//export/home/pgfarm/gcc/HEAD/inst/bin/createuser -R -S -D -q connectdb testing connect/test1.pgc ... skipped testing connect/test2.pgc ... ./pg_regress: bad substitution make[1]: Leaving directory `/export/home/pgfarm/gcc/HEAD/pgsql.28740/src/interfaces/ecpg/test' which says that (a) we have a scripting bug, and (b) some other layer is failing to notice the failure. Which is two separate bugs by my count. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
Tom Lane wrote: AFAICS, Peter's recent incomplete updating of error message wording should have broken every last man jack of 'em. And yet there's still some green to be seen. I think we are looking at problems in the ecpg test scaffolding. Yes. The buildfarm script uses the same logic as other tests: my $ecpg_dir = $pgsql/src/interfaces/ecpg; my @makeout = `cd $ecpg_dir $make NO_LOCALE=1 check 21`; my $status = $? 8; The sooner we move to a more unified testing infrastructure the better. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
On Mon, Jun 04, 2007 at 03:30:07AM -0400, Tom Lane wrote: AFAICS, Peter's recent incomplete updating of error message wording should have broken every last man jack of 'em. And yet there's still some green to be seen. I think we are looking at problems in the ecpg test scaffolding. For instance, dragonfly claims a green build, but http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dragonflydt=2007-06-04%20043001stg=ecpg-check shows this interesting trace: ... testing connect/test2.pgc ... ./pg_regress: bad substitution Is it possible to find out which line is reporting this error? Looks to me like some incompatibility on the shell side. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
Michael Meskes wrote: On Mon, Jun 04, 2007 at 03:30:07AM -0400, Tom Lane wrote: AFAICS, Peter's recent incomplete updating of error message wording should have broken every last man jack of 'em. And yet there's still some green to be seen. I think we are looking at problems in the ecpg test scaffolding. For instance, dragonfly claims a green build, but http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dragonflydt=2007-06-04%20043001stg=ecpg-check shows this interesting trace: ... testing connect/test2.pgc ... ./pg_regress: bad substitution Is it possible to find out which line is reporting this error? Looks to me like some incompatibility on the shell side. turnip_moth is also a Solaris 9 box and doesn't seem have the same issue. Kris, is there anything unusual installed on the box that would make it behave like this? cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
On Mon, 4 Jun 2007, Andrew Dunstan wrote: turnip_moth is also a Solaris 9 box and doesn't seem have the same issue. Kris, is there anything unusual installed on the box that would make it behave like this? Not sure what's going on here. I did a manual run of the ecpg tests and it completed normally. This machine is quite out of date and it has a large mix of GNU tools with the solaris ones. Since turnip_moth is maintained by Sun I would expect it to be up to date on patches and have few non-Sun tools installed. So it could be using a different interpreter or it could be using a broken tool for which a patch has been released. I'll try doing a run with the buildfarm client later today to try and reproduce this. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
