Porting/platforms/buildfarm open issues
First, we still do not have any test with 8.0 on the following platforms:
HP-UX
IRIX
Tru64 UNIX
SCO OpenServer
Second, we have regressions (vs. 7.4) on the following platforms:
Linux Alpha (buildfarm hare)
Linux ARM (see http://archives.postgresql.org/pgsql-hackers/2005-01/msg00094.php)
Other open targets can be found here:
http://developer.postgresql.org/docs/postgres/supported-platforms.html
but those were the most important ones.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Thursday 06 Jan 2005 3:52 pm, Peter Eisentraut wrote:
First, we still do not have any test with 8.0 on the following platforms:
HP-UX
All the 96 tests are passed on RC3. I can rerun the tests with additional
configure flags if required..But I can not install anything new on HP-UX
machine.
$ ./configure --without-readline --without-zlib;gmake;gmake check
$ uname -a
HP-UX machine B.11.00 A 9000/785 2005950738 two-user license
FWIW, I also ran on my Linux machine. It passes there as well..
$ ./configure;make;make check
$ uname -a
Linux machine 2.6.7 #1 Wed Jun 16 16:23:03 PDT 2004 i686 unknown unknown
GNU/Linux
$ cat /etc/slackware-version
Slackware 10.0.0
Shridhar
Hello.
From: Peter Eisentraut <peter_e@gmx.net>
Subject: [HACKERS] Porting/platforms/buildfarm open issues
Date: Thu, 6 Jan 2005 11:22:56 +0100
Tru64 UNIX
I tried RC3 on Tru64 box with cc(Compaq C V6.1-011). There are some errors
to build and install. All tests (make installcheck) are passed.
bash-2.05b$ uname -a
OSF1 kiss.my.domain V5.0 910 alpha
bash-2.05b$ make installcheck
...
======================
All 96 tests passed.
======================
Error Reports:
(Sorry for my poor English.)
1) configure?
I got below error when simply configure and make:
/usr/bin/ld -shared -expect_unresolved '*' fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o getaddrinfo.o -L../../../src/port -lresolv -Wl,-rpath -Wl,/usr/local/pgsql/lib -o libpq.so.3.2
/usr/bin/ld:
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
/usr/bin/ld: Usage: /usr/bin/ld [options] file [...]
make[3]: *** [libpq.so.3.2] Error 1
In Makefile.osf, rpath are defined as 'rpath = -Wl,-rpath -Wl,$(rpathdir)'. But,
Makefile.global were set LD to /usr/bin/ld by configure script:
bash-2.05b$ grep "LD " Makefile.global
LD = /usr/bin/ld
So, I need a patch to build:
bash-2.05b$ diff Makefile.osf.DIST Makefile.osf
4c4
< rpath = -Wl,-rpath -Wl,$(rpathdir)
---
rpath = -rpath $(rpathdir)
(Because LDREL=-r is fixed in Makefile.global.in and cc command can not pass "-r"
flag to linker, I did not set LD environment vriable to "/usr/bin/cc".)
I believe that it will be no problem if I had used gcc.
2) mkdir?
Due to odd behavior of 'mkdir -p' command, I got below error when 'make install':
mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share
mkdir: cannot create /usr/local/pgsql/share.
/usr/local/pgsql/share: File exists
make[2]: *** [installdirs] Error 2
So, i needed patches below:
bash-2.05b$ diff include/Makefile.DIST include/Makefile
21c21
< nodes optimizer parser port regex rewrite storage tcop utils \
---
nodes optimizer parser regex rewrite storage tcop utils \
(port directory were specified twice.)
bash-2.05b$ diff backend/Makefile.DIST backend/Makefile
184c184
< $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(datadir)
---
$(mkinstalldirs) $(DESTDIR)$(datadir) $(DESTDIR)$(bindir)
(The mkdir command(of OS standard) fail if there are no-existing directory in middle
of paths of the argument. For example,
bash-2.05b$ mkdir abc --- success.
bash-2.05b$ mkdir -p abc abc2 --- success. the last 'abc2' don't exist.
bash-2.05b$ mkdir -p abc3 abc abc2 --- failure. the first 'abc3' don't exist
mkdir: cannot create abc.
abc: File exists
bash-2.05b$ mkdir -p abc5 abc5 --- failuer. both of 'abc5' don't exist
mkdir: cannot create abc5.
abc5: File exists
)
regards,
--
Shigehiro Honda
Shridhar Daithankar <ghodechhap@ghodechhap.net> writes:
On Thursday 06 Jan 2005 3:52 pm, Peter Eisentraut wrote:
First, we still do not have any test with 8.0 on the following platforms:
HP-UX
All the 96 tests are passed on RC3. I can rerun the tests with additional
configure flags if required..But I can not install anything new on HP-UX
machine.
$ ./configure --without-readline --without-zlib;gmake;gmake check
$ uname -a
HP-UX machine B.11.00 A 9000/785 2005950738 two-user license
I can assure you it works on 10.20 as well ;-)
$ uname -a
HP-UX sss2 B.10.20 C 9000/780 2004473515 32-user license
I have done port testing using both gcc and vendor's cc on HPUX 11.11
(PA-RISC) and 11.23 (Itanium) at HP's testdrive farm. The last time was
a month or two back, so it's possible that something broke since then,
but it seems highly unlikely. It's also been a month or two since I
last tried vendor's cc on 10.20, but I doubt that broke either.
regards, tom lane
Peter Eisentraut wrote:
Second, we have regressions (vs. 7.4) on the following platforms:
Linux Alpha (buildfarm hare)
This was apparently an old Alpha chip, and Jim was going to try on a
more modern machine not known to have FP problems. So take this result
with many grains of salt.
cheers
andrew
Honda Shigehiro <fwif0083@mb.infoweb.ne.jp> writes:
So, I need a patch to build:
bash-2.05b$ diff Makefile.osf.DIST Makefile.osf
4c4
< rpath = -Wl,-rpath -Wl,$(rpathdir)
---rpath = -rpath $(rpathdir)
OK; this simply reverts a cosmetic change I made awhile ago. Evidently
that wasn't a good idea on all platforms after all :-(
Due to odd behavior of 'mkdir -p' command, I got below error when 'make install':
mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share
mkdir: cannot create /usr/local/pgsql/share.
I think you ought to report this as a bug in the local version of mkdir.
bash-2.05b$ diff backend/Makefile.DIST backend/Makefile
184c184
< $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(datadir)
---$(mkinstalldirs) $(DESTDIR)$(datadir) $(DESTDIR)$(bindir)
I'm not following the point of this change?
regards, tom lane
Am Donnerstag, 6. Januar 2005 16:30 schrieb Honda Shigehiro:
2) mkdir?
Due to odd behavior of 'mkdir -p' command, I got below error when 'make
install': mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share
mkdir: cannot create /usr/local/pgsql/share.
/usr/local/pgsql/share: File exists
make[2]: *** [installdirs] Error 2
Would you place the attached version of mkinstalldirs in the config/ directory
in the PostgreSQL source tree and try installing again? (Of course, you
might need to delete /usr/local/pgsql first to have the same preconditions.)
Please report whether it works better.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Attachments:
Hello,
This installdirs are worked well. 'make install' succeeds without
modifying Makefiles.
Thank you.
regards,
--
Shigehiro Honda
From: Peter Eisentraut <peter_e@gmx.net>
Subject: Re: [HACKERS] Porting/platforms/buildfarm open issues
Date: Fri, 7 Jan 2005 10:53:56 +0100
Show quoted text
Am Donnerstag, 6. Januar 2005 16:30 schrieb Honda Shigehiro:
2) mkdir?
Due to odd behavior of 'mkdir -p' command, I got below error when 'make
install': mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share
mkdir: cannot create /usr/local/pgsql/share.
/usr/local/pgsql/share: File exists
make[2]: *** [installdirs] Error 2Would you place the attached version of mkinstalldirs in the config/ directory
in the PostgreSQL source tree and try installing again? (Of course, you
might need to delete /usr/local/pgsql first to have the same preconditions.)
Please report whether it works better.--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Am Freitag, 7. Januar 2005 13:10 schrieb Honda Shigehiro:
This installdirs are worked well. 'make install' succeeds without
modifying Makefiles.
Does anyone object to installing the new mkinstalldirs? I took the latest
version from the automake CVS. The important change was apparently to use
mkdir -p only with GNU mkdir.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
Does anyone object to installing the new mkinstalldirs? I took the latest
version from the automake CVS. The important change was apparently to use
mkdir -p only with GNU mkdir.
Could you post a diff against what we have now?
regards, tom lane
Am Freitag, 7. Januar 2005 17:20 schrieb Tom Lane:
Does anyone object to installing the new mkinstalldirs? I took the
latest version from the automake CVS. The important change was
apparently to use mkdir -p only with GNU mkdir.Could you post a diff against what we have now?
Attached.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Attachments:
mkinstalldirs.difftext/x-diff; charset=iso-8859-15; name=mkinstalldirs.diffDownload
*** devel/pg75/cvs-pgsql/config/mkinstalldirs 2003-11-04 11:59:58.000000000 +0100
--- mkinstalldirs 2005-01-07 10:51:26.000000000 +0100
***************
*** 1,20 ****
#! /bin/sh
# mkinstalldirs --- make directory hierarchy
! # Author: Noah Friedman <friedman@prep.ai.mit.edu>
# Created: 1993-05-16
! # Public domain
errstatus=0
dirmode=""
usage="\
! Usage: mkinstalldirs [-h] [--help] [-m mode] dir ..."
# process command line arguments
while test $# -gt 0 ; do
case $1 in
-h | --help | --h*) # -h for help
! echo "$usage" 1>&2
exit 0
;;
-m) # -m PERM arg
--- 1,32 ----
#! /bin/sh
# mkinstalldirs --- make directory hierarchy
!
! scriptversion=2004-02-15.20
!
! # Original author: Noah Friedman <friedman@prep.ai.mit.edu>
# Created: 1993-05-16
! # Public domain.
! #
! # This file is maintained in Automake, please report
! # bugs to <bug-automake@gnu.org> or send patches to
! # <automake-patches@gnu.org>.
errstatus=0
dirmode=""
usage="\
! Usage: mkinstalldirs [-h] [--help] [--version] [-m MODE] DIR ...
!
! Create each directory DIR (with mode MODE, if specified), including all
! leading file name components.
!
! Report bugs to <bug-automake@gnu.org>."
# process command line arguments
while test $# -gt 0 ; do
case $1 in
-h | --help | --h*) # -h for help
! echo "$usage"
exit 0
;;
-m) # -m PERM arg
***************
*** 23,28 ****
--- 35,44 ----
dirmode=$1
shift
;;
+ --version)
+ echo "$0 $scriptversion"
+ exit 0
+ ;;
--) # stop option processing
shift
break
***************
*** 50,66 ****
0) exit 0 ;;
esac
case $dirmode in
'')
! if mkdir -p -- . 2>/dev/null; then
echo "mkdir -p -- $*"
exec mkdir -p -- "$@"
fi
;;
*)
! if mkdir -m "$dirmode" -p -- . 2>/dev/null; then
echo "mkdir -m $dirmode -p -- $*"
exec mkdir -m "$dirmode" -p -- "$@"
fi
;;
esac
--- 66,102 ----
0) exit 0 ;;
esac
+ # Solaris 8's mkdir -p isn't thread-safe. If you mkdir -p a/b and
+ # mkdir -p a/c at the same time, both will detect that a is missing,
+ # one will create a, then the other will try to create a and die with
+ # a "File exists" error. This is a problem when calling mkinstalldirs
+ # from a parallel make. We use --version in the probe to restrict
+ # ourselves to GNU mkdir, which is thread-safe.
case $dirmode in
'')
! if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
echo "mkdir -p -- $*"
exec mkdir -p -- "$@"
+ else
+ # On NextStep and OpenStep, the `mkdir' command does not
+ # recognize any option. It will interpret all options as
+ # directories to create, and then abort because `.' already
+ # exists.
+ test -d ./-p && rmdir ./-p
+ test -d ./--version && rmdir ./--version
fi
;;
*)
! if mkdir -m "$dirmode" -p --version . >/dev/null 2>&1 &&
! test ! -d ./--version; then
echo "mkdir -m $dirmode -p -- $*"
exec mkdir -m "$dirmode" -p -- "$@"
+ else
+ # Clean up after NextStep and OpenStep mkdir.
+ for d in ./-m ./-p ./--version "./$dirmode";
+ do
+ test -d $d && rmdir $d
+ done
fi
;;
esac
***************
*** 84,100 ****
mkdir "$pathcomp" || lasterr=$?
if test ! -d "$pathcomp"; then
! errstatus=$lasterr
else
! if test ! -z "$dirmode"; then
echo "chmod $dirmode $pathcomp"
! lasterr=""
! chmod "$dirmode" "$pathcomp" || lasterr=$?
! if test ! -z "$lasterr"; then
! errstatus=$lasterr
! fi
! fi
fi
fi
--- 120,136 ----
mkdir "$pathcomp" || lasterr=$?
if test ! -d "$pathcomp"; then
! errstatus=$lasterr
else
! if test ! -z "$dirmode"; then
echo "chmod $dirmode $pathcomp"
! lasterr=""
! chmod "$dirmode" "$pathcomp" || lasterr=$?
! if test ! -z "$lasterr"; then
! errstatus=$lasterr
! fi
! fi
fi
fi
***************
*** 107,111 ****
# Local Variables:
# mode: shell-script
# sh-indentation: 2
# End:
- # mkinstalldirs ends here
--- 143,150 ----
# Local Variables:
# mode: shell-script
# sh-indentation: 2
+ # eval: (add-hook 'write-file-hooks 'time-stamp)
+ # time-stamp-start: "scriptversion="
+ # time-stamp-format: "%:y-%02m-%02d.%02H"
+ # time-stamp-end: "$"
# End:
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility (Oracle
PL/SQL).
It made porting much easier, but our experience show that it
would be now also not very difficult with other databases like PostgreSQL.
Compiere contained lot of PL/SQL which size is now largely reduced.
Main problem is some SQL constructions which are not supported.
Particulary something like this is very important:
UPDATE sometable set (col1,col2) = (select col_a,col_b from another_table
where ....)
This construction seems to be quite useful in another cases.
Would be it diffcult and possible to add such syntax to PostgreSQL ?
Marek Mosiewicz
http://www.jotel.com.pl
Peter Eisentraut <peter_e@gmx.net> writes:
Am Freitag, 7. Januar 2005 17:20 schrieb Tom Lane:
Could you post a diff against what we have now?
Attached.
Looks ok to me.
regards, tom lane
Marek Mosiewicz wrote:
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility
(Oracle
PL/SQL).
It made porting much easier, but our experience show that it
would be now also not very difficult with other databases like
PostgreSQL.
Compiere contained lot of PL/SQL which size is now largely reduced.
Main problem is some SQL constructions which are not supported.
Particulary something like this is very important:
UPDATE sometable set (col1,col2) = (select col_a,col_b from
another_table
where ....)
This construction seems to be quite useful in another cases.Would be it diffcult and possible to add such syntax to PostgreSQL ?
PostgreSQL has limited support for the SQL 92 row constructor. You can
use it in select expressions in most places, but not in update as you
noticed.
Be forewarned that row constructor expressions involving the > or <
operators can give the wrong answer:
select (2,2,3) > (2,1,3)
returns false when it should return true.
Merlin
Import Notes
Resolved by subject fallback
Upps sorry now found it on TODO list.
I was not aware that it is SQL92 standard.
Is it difficult to implement ?
Simplest approach would be
to rewrite it to UPDATE t1 set col1 = (select cola ...), col2 = (select
colb....) ....
but it would result in not optimal plan.
Marek Mosiewicz
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Merlin Moncure
Sent: Friday, January 07, 2005 6:15 PM
To: Marek Mosiewicz
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Compiere ERP and SQL quirks
Marek Mosiewicz wrote:
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility
(Oracle
PL/SQL).
It made porting much easier, but our experience show that it
would be now also not very difficult with other databases like
PostgreSQL.
Compiere contained lot of PL/SQL which size is now largely reduced.
Main problem is some SQL constructions which are not supported.
Particulary something like this is very important:
UPDATE sometable set (col1,col2) = (select col_a,col_b from
another_table
where ....)
This construction seems to be quite useful in another cases.Would be it diffcult and possible to add such syntax to PostgreSQL ?
PostgreSQL has limited support for the SQL 92 row constructor. You can
use it in select expressions in most places, but not in update as you
noticed.
Be forewarned that row constructor expressions involving the > or <
operators can give the wrong answer:
select (2,2,3) > (2,1,3)
returns false when it should return true.
Merlin
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Marek Mosiewicz wrote:
Upps sorry now found it on TODO list.
I was not aware that it is SQL92 standard.
Is it difficult to implement ?
Simplest approach would be
to rewrite it to UPDATE t1 set col1 = (select cola ...), col2 = (select
colb....) ....
but it would result in not optimal plan.
Doesn't something like
UPDATE t1 SET col1=cola, col2=colb
FROM t1 JOIN anothertable ot ON t1.id=ot.id
WHERE ...
Work the way you'd like it? I'd expect this syntax to be as widely
portable and performant.
Regards,
Andreas
Andreas wrote:
Marek Mosiewicz wrote:
Upps sorry now found it on TODO list.
I was not aware that it is SQL92 standard.
Is it difficult to implement ?
Simplest approach would be
to rewrite it to UPDATE t1 set col1 = (select cola ...), col2 =
(select
colb....) ....
but it would result in not optimal plan.Doesn't something like
UPDATE t1 SET col1=cola, col2=colb
FROM t1 JOIN anothertable ot ON t1.id=ot.id
WHERE ...Work the way you'd like it? I'd expect this syntax to be as widely
portable and performant.
Hmm, 'from' in an update is a PostgreSQL extension to the update command
:).
Merlin
Import Notes
Resolved by subject fallback
On Fri, 7 Jan 2005, Merlin Moncure wrote:
Marek Mosiewicz wrote:
Hello
We made Compiere (Open source ERP system) to Firebird (Fyracle)
This is special version of Firebird with added Oracle compatibility
(Oracle
PL/SQL).
It made porting much easier, but our experience show that it
would be now also not very difficult with other databases likePostgreSQL.
Compiere contained lot of PL/SQL which size is now largely reduced.
Main problem is some SQL constructions which are not supported.
Particulary something like this is very important:
UPDATE sometable set (col1,col2) = (select col_a,col_b from
another_table
where ....)
This construction seems to be quite useful in another cases.Would be it diffcult and possible to add such syntax to PostgreSQL ?
PostgreSQL has limited support for the SQL 92 row constructor. You can
use it in select expressions in most places, but not in update as you
noticed.
Umm, SQL92 doesn't appear to allow row constructors at that place in
update as far as I can tell.
<set clause list> ::=
<set clause> [ { <comma> <set clause> }... ]
<set clause> ::=
<object column> <equals operator> <update source>
<update source> ::=
<value expression>
| <null specification>
| DEFAULT
<object column> ::= <column name>
Merlin Moncure wrote:
Andreas wrote:
Doesn't something like
UPDATE t1 SET col1=cola, col2=colb
FROM t1 JOIN anothertable ot ON t1.id=ot.id
WHERE ...Work the way you'd like it? I'd expect this syntax to be as widely
portable and performant.Hmm, 'from' in an update is a PostgreSQL extension to the update command
:).
Ooops... Oracle doesn't know it, I used to use it on MSSQL.
Regards,
Andreas