Обсуждение: solaris tarballs and pl/java

The tarball for 64bit 8.4.3 on Solaris Sparc is missing some ./pgxs/...
files I seem to need to build pl/java.  they exist in the 32bit version
but at least of them, Makefile.global, appears quite build specific.


$ ls -l 8.4-community/lib/pgxs/src/
total 91
-r--r--r--   1 postgres postgres   19618 Mar 12 07:56 Makefile.global
-r--r--r--   1 postgres postgres     434 Mar 12 07:56 Makefile.port
-r--r--r--   1 postgres postgres   15738 Mar 12 07:56 Makefile.shlib
drwxr-xr-x   2 postgres postgres       3 Mar 12 07:56 makefiles
-r--r--r--   1 postgres postgres    4734 Mar 12 07:56 nls-global.mk
drwxr-xr-x   3 postgres postgres       3 Mar 12 04:59 test

$ ls -l 8.4-community/lib/64/pgxs/src/
total 6
drwxr-xr-x   2 postgres postgres       3 Mar 12 08:11 makefiles
drwxr-xr-x   3 postgres postgres       3 Mar 12 04:59 test

now, I suppose I could try to hack up the 32bit one and copy it to the
64bit dir myself, but there's a lot of complex stuff in that file and
way too much room for error for my tastes.

John R Pierce wrote:
> The tarball for 64bit 8.4.3 on Solaris Sparc is missing some
> ./pgxs/... files I seem to need to build pl/java.  they exist in the
> 32bit version but at least of them, Makefile.global, appears quite
> build specific.

Yeah, it seemed pretty obvious from the error you were running into in
your last message that you'll need to do your own PostgreSQL build here
first, then add pl/java on top of that.  Binary packages aren't
necessarily good at giving you everything needed to build your
extensions, and even if it did build I'd be suspicious of it until it
passed testing.

You can see more about how the OpenSolaris packages are built at
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/ ;
Makefile.sfw in particular might have clues as to what's going wrong
here.  There are separate code paths in several places there for 32 vs.
64 bit builds, and you seem to have run into a divergence between the two.

As for mailing lists, you can try
http://lists.pgfoundry.org/pipermail/pljava-dev/ for things specific to
building it.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us

Greg Smith wrote:
> John R Pierce wrote:
>> The tarball for 64bit 8.4.3 on Solaris Sparc is missing some
>> ./pgxs/... files I seem to need to build pl/java.  they exist in the
>> 32bit version but at least of them, Makefile.global, appears quite
>> build specific.
>
> Yeah, it seemed pretty obvious from the error you were running into in
> your last message that you'll need to do your own PostgreSQL build
> here first, then add pl/java on top of that.  Binary packages aren't
> necessarily good at giving you everything needed to build your
> extensions, and even if it did build I'd be suspicious of it until it
> passed testing.
>
> You can see more about how the OpenSolaris packages are built at
> http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/ ;
> Makefile.sfw in particular might have clues as to what's going wrong
> here.  There are separate code paths in several places there for 32
> vs. 64 bit builds, and you seem to have run into a divergence between
> the two.
>
> As for mailing lists, you can try
> http://lists.pgfoundry.org/pipermail/pljava-dev/ for things specific
> to building it.
>

having not gone down the path of building my own language extensions
before, how portable are they between postgres builds?    What I build
needs to eventually be installable on a 8.4-community 64bit install as
they want to add pl/java support to a running production database.   I
can specify they use the same JDK etc.

Last night, I started trying to piece together the environment for
./configure for postgres based on what pg_config gives me, but it
aborted pretty early with missing stuffs...  by then it was 1am and I
was fried so I am taking a fresh look this morning...   k, I'm already
farther along and moving forward... (had to add /usr/sbin to the path to
find dtrace, now I'm sorting out readline vs libedit...)... and stopped
on a 'cannot compute size(off_t)' but I'm sure I'll figure that out...

John R Pierce wrote:
> Last night, I started trying to piece together the environment for
> ./configure for postgres based on what pg_config gives me, but it
> aborted pretty early with missing stuffs...  by then it was 1am and I
> was fried so I am taking a fresh look this morning...   k, I'm already
> farther along and moving forward... (had to add /usr/sbin to the path
> to find dtrace, now I'm sorting out readline vs libedit...)... and
> stopped on a 'cannot compute size(off_t)' but I'm sure I'll figure
> that out...

so, i'm stuck here.

getting this error from thte ./configure:

    configure:16808: error: cannot compute sizeof (off_t)

I'm trying to mimic this pg_config...

$ pg_config
BINDIR = /usr/postgres/8.4-community/bin/64
DOCDIR = /usr/postgres/8.4-community/share/doc
HTMLDIR = /usr/postgres/8.4-community/share/doc
INCLUDEDIR = /usr/postgres/8.4-community/include
PKGINCLUDEDIR = /usr/postgres/8.4-community/include
INCLUDEDIR-SERVER = /usr/postgres/8.4-community/include/server
LIBDIR = /usr/postgres/8.4-community/lib/64
PKGLIBDIR = /usr/postgres/8.4-community/lib/64
LOCALEDIR = /usr/postgres/8.4-community/share/locale
MANDIR = /usr/postgres/8.4-community/man
SHAREDIR = /usr/postgres/8.4-community/share
SYSCONFDIR = /usr/postgres/8.4-community/etc
PGXS = /usr/postgres/8.4-community/lib/64/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--prefix=/usr/postgres/8.4-community'
'--exec-prefix=/usr/postgres/8.4-community'
'--bindir=/usr/postgres/8.4-community/bin/64'
'--libexecdir=/usr/postgres/8.4-community/bin/64'
'--sbindir=/usr/postgres/8.4-community/bin/64'
'--datadir=/usr/postgres/8.4-community/share'
'--sysconfdir=/usr/postgres/8.4-community/etc'
'--mandir=/usr/postgres/8.4-community/man'
'--libdir=/usr/postgres/8.4-community/lib/64'
'--includedir=/usr/postgres/8.4-community/include'
'--sharedstatedir=/var/postgres/8.4-community'
'--localstatedir=/var/postgres/8.4-community'
'--with-system-tzdata=/usr/share/lib/zoneinfo' '--enable-nls'
'--with-docdir=/usr/postgres/8.4-community/doc' '--with-python'
'--with-pam' '--with-openssl' '--with-libedit-preferred' '--with-libxml'
'--with-libxslt' '--with-gssapi' '--enable-thread-safety'
'--enable-dtrace' 'DTRACEFLAGS=-64'

'--with-includes=/zstore/pgsql/pg84b1/proto/root_sparc/usr/include:/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include:/usr/sfw/include'

'--with-tclconfig=/usr/sfw/lib'

'--with-libs=/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64:/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/lib/64:/usr/lib/64:/usr/sfw/lib/64'

'CC=/opt/SUNWspro/SS11/bin/cc' 'CFLAGS=-xO3 -xarch=v9 -dalign
-Wc,-Qiselect-regsym=0 -xspace -W0,-Lt -W2,-Rcond_elim -Xa  -xildoff '
'LDFLAGS=-L/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64
-L/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/lib/64
-L/usr/sfw/lib/64'
'CPPFLAGS=-I/zstore/pgsql/pg84b1/proto/root_sparc/usr/include
-I/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include -I/usr/sfw/include'
CC = /opt/SUNWspro/SS11/bin/cc
CPPFLAGS = -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/include
-I/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include
-I/usr/sfw/include -I/usr/include/libxml2
-I/zstore/pgsql/pg84b1/proto/root_sparc/usr/include
-I/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include -I/usr/sfw/include
CFLAGS = -xO3 -xarch=v9 -dalign   -Wc,-Qiselect-regsym=0 -xspace -W0,-Lt
-W2,-Rcond_elim -Xa  -xildoff
CFLAGS_SL = -KPIC
LDFLAGS = -L/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64
-L/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/lib/64 -L/usr/sfw/lib/64
-L/usr/lib -L/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64
-L/usr/lib/64 -L/usr/sfw/lib/64 -Wl,-R'/usr/postgres/8.4-community/lib/64'
LDFLAGS_SL =
LIBS = -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lgss -lz -ledit
-ltermcap -lnsl -lrt -lsocket -lm
VERSION = PostgreSQL 8.4.3


and I'm using this configure script...

$ more configit
export JAVA_HOME=/usr/jdk/jdk1.5.0_23
export

PATH=/usr/jdk/jdk1.5.0_23/bin/sparcv9:/opt/SUNWspro/bin:/usr/postgres/8.4-community/bin/64:/usr/bin:/usr/sbin:/opt/sfw/bin:/usr/sfw/bin:/usr/local/bin:/usr/ccs/bin

export CC=/opt/SUNWspro/bin/cc
export CFLAGS='-xO3 -xarch=v9 -dalign -Wc,-Qiselect-regsym=0 -xspace
-W0,-Lt -W2,-Rcond_elim -Xa  -xildoff'
export CFLAGS_SL=-KPIC
export LDFLAGS="-L/usr/lib/64 -L/usr/sfw/lib/64 -L/usr/sfw/lib/64
-L/usr/lib -L/usr/lib/64 -L/usr/lib/64 -L/usr/sfw/lib/64
-Wl,-R'/usr/postgres/8.4-community/lib/64'"
export CPPFLAGS='-I/usr/include -I/usr/sfw/include -I/usr/sfw/include
-I/usr/include/libxml2 -I/usr/include -I/usr/sfw/include -I/usr/sfw/include'

export CONFSTUFF='--prefix=/usr/postgres/8.4-community
--exec-prefix=/usr/postgres/8.4-community --bindir=/usr/postgres
/8.4-community/bin/64 --libexecdir=/usr/postgres/8.4-community/bin/64
--sbindir=/usr/postgres/8.4-community/bin/64 --da
tadir=/usr/postgres/8.4-community/share
--sysconfdir=/usr/postgres/8.4-community/etc
--mandir=/usr/postgres/8.4-communi
ty/man --libdir=/usr/postgres/8.4-community/lib/64
--includedir=/usr/postgres/8.4-community/include --sharedstatedir=/v
ar/postgres/8.4-community --localstatedir=/var/postgres/8.4-community
--with-system-tzdata=/usr/share/lib/zoneinfo --en
able-nls --with-docdir=/usr/postgres/8.4-community/doc --with-python
--with-pam --with-openssl --with-libedit-preferred
 --with-libxml --with-libxslt --with-gssapi --enable-thread-safety
--enable-dtrace DTRACEFLAGS=-64 --with-includes=/usr
/include:/usr/sfw/include --with-tclconfig=/usr/sfw/lib
--with-libs=/usr/lib/64:/usr/sfw/lib/64'

./configure $CONFSTUFF --without-readline

(I shut readline off, cuz I wanted to get past something lame there)

my cc compiler is...

$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22
usage: cc [ options] files.  Use 'cc -flags' for details

and my java is...

$ /usr/jdk/jdk1.5.0_23/bin/sparcv9/java -version
java version "1.5.0_23"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_23-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_23-b01, mixed mode)

John R Pierce <pierce@hogranch.com> writes:
> getting this error from thte ./configure:
>     configure:16808: error: cannot compute sizeof (off_t)

That's pretty weird.  Look into the config.log output to see why that
particular test program is failing.  (The relevant bit will probably be
a few hundred lines before the end of config.log --- the last section
of the log is a dump of the current values of all of configure's
variables, and there are a lot...)

BTW, which 8.4.x PG release is this exactly?

            regards, tom lane

On 15/04/2010 20:44, Ozz Nixon wrote:
> Would this syntax work in PostgreSQL?
>
> |INSERT INTO MyTable (FirstCol, SecondCol)
> VALUES ('First',1),
> || ('||Second||',2),|
> | ('||Third||',3),|
> | ('||Fourth||',4),|
> | ('||Fifth||',5)||
> |
> Inserting 5 rows in a single Insert? (I am trying to implement this
> solution across many different backends) works on SQL Server 2008, need
> to make sure it will work on many others.

http://www.postgresql.org/docs/8.4/static/sql-insert.html


--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie

Ozz Nixon escribió:
> Would this syntax work in PostgreSQL?
>
> |INSERT INTO MyTable (FirstCol, SecondCol)
> VALUES ('First',1),
> || ('||Second||',2),|
> | ('||Third||',3),|
> | ('||Fourth||',4),|
> | ('||Fifth||',5)||

Yes, it works (without all those funny || though)

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Tom Lane wrote:
> John R Pierce <pierce@hogranch.com> writes:
>
>> getting this error from thte ./configure:
>>     configure:16808: error: cannot compute sizeof (off_t)
>>
>
> That's pretty weird.  Look into the config.log output to see why that
> particular test program is failing.  (The relevant bit will probably be
> a few hundred lines before the end of config.log --- the last section
> of the log is a dump of the current values of all of configure's
> variables, and there are a lot...)
>
> BTW, which 8.4.x PG release is this exactly?
>


its 8.4.3 ...   I'm jumping sideways and trying a different attack on my
actual problem, which is building pl/java HEAD for 64bit solaris sparc
w/ 8.4.3 and JDK 1.5.0_23...   rather than building the entire postgres
tree, I replicated the couple missing files from the 32bit version and
am 'fixing' their paths.

I'm hitting another problem with that,  but I think I'll take it to the
pl/java list.

John R Pierce wrote:
> Tom Lane wrote:
> >John R Pierce <pierce@hogranch.com> writes:
> >>getting this error from thte ./configure:
> >>    configure:16808: error: cannot compute sizeof (off_t)
> >
> >That's pretty weird.  Look into the config.log output to see why that
> >particular test program is failing.  (The relevant bit will probably be
> >a few hundred lines before the end of config.log --- the last section
> >of the log is a dump of the current values of all of configure's
> >variables, and there are a lot...)
> >
> >BTW, which 8.4.x PG release is this exactly?
>
> its 8.4.3 ...   I'm jumping sideways and trying a different attack
> on my actual problem, which is building pl/java HEAD for 64bit
> solaris sparc w/ 8.4.3 and JDK 1.5.0_23...   rather than building
> the entire postgres tree, I replicated the couple missing files from
> the 32bit version and am 'fixing' their paths.

Even if you are able to get that to compile, it's likely to fall over at
run time.  Why not just build the complete tree?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On 4/15/2010 11:59 AM, John R Pierce wrote:
> The tarball for 64bit 8.4.3 on Solaris Sparc is missing some ./pgxs/...
> files I seem to need to build pl/java. they exist in the 32bit version
> but at least of them, Makefile.global, appears quite build specific.
>

So, it seem to be painful to compile the java stuff... and upthread you
said someone "was more comfortable with java" and they were doing "some
sorta-statistical calculations"... is it really worth all that?

They could do it in perl and it would probably be just as fast.  I mean,
they arent gonna write _that_ much stored procedure code, are they?

If they had questions there are several on this list that could help
them convert java to perl.

I'm just wondering... which is more expensive?

1) painful install pl/java, develop SP
2) install pl/perl, painful develop SP

-Andy

Alvaro Herrera wrote:
>> ... 8.4.3 ...   I'm jumping sideways and trying a different attack
>> on my actual problem, which is building pl/java HEAD for 64bit
>> solaris sparc w/ 8.4.3 and JDK 1.5.0_23...   rather than building
>> the entire postgres tree, I replicated the couple missing files from
>> the 32bit version and am 'fixing' their paths.
>>
>
> Even if you are able to get that to compile, it's likely to fall over at
> run time.  Why not just build the complete tree?
>

because, to make a long story short, the 'operations' people want to
eventually install this onto a running production postgres server.

Andy Colson wrote:
> On 4/15/2010 11:59 AM, John R Pierce wrote:
>> The tarball for 64bit 8.4.3 on Solaris Sparc is missing some ./pgxs/...
>> files I seem to need to build pl/java. they exist in the 32bit version
>> but at least of them, Makefile.global, appears quite build specific.
>>
>
> So, it seem to be painful to compile the java stuff... and upthread
> you said someone "was more comfortable with java" and they were doing
> "some sorta-statistical calculations"... is it really worth all that?
>
> They could do it in perl and it would probably be just as fast.  I
> mean, they arent gonna write _that_ much stored procedure code, are they?
>
> If they had questions there are several on this list that could help
> them convert java to perl.
>
> I'm just wondering... which is more expensive?
>
> 1) painful install pl/java, develop SP
> 2) install pl/perl, painful develop SP

They have their code running now in pl/java on a Windows dev platform.
but the production database this is targeted at is Solaris/Sparc

in fact, the *original* SP was in plsql on an Oracle database, but it
made use of some oracle features which are not in Postgres, something
called "Oracle Pipelined Table" (I don't even know what this is).

if it was me writing the code, I'd be doing it in perl, no problem.
Their attitude is, pljava and SQLJ are a standard, plperl isn't.

anyways, I've got it all built now, and am just sorting out loading
problems, I've moved over to the pljava-dev list for assistance on my
current problems as this list is failrly java-hostile.

On Thu, Apr 15, 2010 at 1:49 PM, Raymond O'Donnell <rod@iol.ie> wrote:
> On 15/04/2010 20:44, Ozz Nixon wrote:
>> Would this syntax work in PostgreSQL?
>>
>> |INSERT INTO MyTable (FirstCol, SecondCol)
>> VALUES ('First',1),
>> || ('||Second||',2),|
>> | ('||Third||',3),|
>> | ('||Fourth||',4),|
>> | ('||Fifth||',5)||
>> |
>> Inserting 5 rows in a single Insert? (I am trying to implement this
>> solution across many different backends) works on SQL Server 2008, need
>> to make sure it will work on many others.
>
> http://www.postgresql.org/docs/8.4/static/sql-insert.html

Remove the | symbols and it should