Re: PL/Java 1.5.1_BETA2 - Mailing list pgsql-pkg-debian

On 09/16/18 16:18, Christoph Berg wrote:

> i.e. it's replacing both occurrences of "i386" by "1".

Ok, that's irritating. I can guess what is happening. I implement the
-Dpljava.libjvmdefault by passing the string into cpp with a -D, and that
gets converted to a string using the CppAsString2 macro, and that apparently
is not protected from expansion of other macros, and I bet something is
defining i386 to be 1.

Phooey.

I don't know if that will be easy to fix using cpp. An alternative would be
to pass it to cpp already quoted according to C rules, but that would be
somewhat ugly to express in a Maven build script.

> (same session was running "create extension pljava" earlier)
> # set pljava.libjvm_location = '/usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so';
> HINWEIS:  00000: PL/Java load successful after failed CREATE EXTENSION
> DETAIL:  PL/Java is now installed, but not as an extension.
> TIP:  To correct that, either COMMIT or ROLLBACK, make sure the working settings are saved, exit this session, and in
anew session, either: 1. if committed, run "CREATE EXTENSION pljava FROM unpackaged", or 2. if rolled back, simply
"CREATEEXTENSION pljava" again.
 
> ORT:  initsequencer, Backend.c:654
> 
> Why does tell me that this installation is not from an extension?

Your original CREATE EXTENSION command did not succeed, reporting the error
trying to load the library.

Your SET command to correct the library name completed the installation
of PL/Java, but at that point it was no longer within a CREATE EXTENSION
command, so the various functions, tables, etc., have just been installed
'loose' (exactly as they would if you were installing in 9.0 or earlier
with no 'extension' mechanism).

The TIP describes how to proceed so they will all be grouped together
as a named extension, just as would have happened had the jvm path been
correct when the CREATE EXTENSION command was first given.

> Proceeding to load the examples:

> Server beendete die Verbindung unerwartet

Is there anything in the server log with details of the crash?
In many cases there will be a lengthy message from the JVM in the server
log, and that message will contain a file name (something like
/tmp/hs_err_pidnnnn.log) which will contain *even more* detail.
I would be interested to see that. Was this still on i386 ?

> Another question: Docs say
>   mvn -Dpgsql.pgconfig=...
>   java -Dpgconfig=/local/pgsql/bin/pg_config -jar pljava-packaging/...
> I had first tried mvn -Dpgconfig, which didn't work - is it really two
> different variable names?

They are different. Maven has a very large number of named properties,
often in prefix.foo form, so I followed that pattern, but the self-install
jar has very few.

> And is -Dpgconfig even used if for the installer, when
> -Dpgconfig.pkglibdir and -Dpgconfig.sharedir are given? I need to
> point these to debian/postgresql-$version-pljava/usr/... A "DESTDIR"
> mechanism would be nice to have here.

I think -Dpgconfig will not be used, if explicit -Dpgconfig.foo values
are given for all pljava/foo directory prefixes appearing in the jar.
As pkglibdir and sharedir are the only ones I see in the jar, it
should be sufficient to explicitly supply those two.

> 20:07:07 ERROR:  java.lang.ClassNotFoundException: org.postgresql.pljava.example.annotation.ComplexTuple
> 20:07:07 CONTEXT:  SQL statement "SELECT javatest.assertHasValues( CAST('(1,2)' AS javatest.complextuple), 1, 2)"

I believe you'll find this a Heisenbug, and it will go away if you repeat
the build and the test. It results from an interaction between the order
of commands in the jar's pljava.ddr file and the way PostgreSQL decides when
to get an updated snapshot. It will go away if you repeat the build because
pljava.ddr is not generated in a fully determined order, but only one that
satisfies the annotated provides/requires relationships. Most orderings do
not show the problem. :)

I had added workarounds already to ComplexScalar and UDTScalarIOTest,
but I must have missed ComplexTuple.


https://github.com/tada/pljava/blob/V1_5_1b2/pljava-examples/src/main/java/org/postgresql/pljava/example/annotation/ComplexScalar.java#L153

https://github.com/tada/pljava/blob/V1_5_1b2/pljava-examples/src/main/java/org/postgresql/pljava/example/annotation/UDTScalarIOTest.java#L221

That can be a github issue. I'll work on that before the release.

> 20:00:43 [ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.2.3:nar-validate
(default-nar-validate)on project pljava-so: NAR: One of two things may be wrong here:
 
> 20:00:43 [ERROR] 1. <Name> tag is missing inside the <Linker> tag of your NAR configuration
> 20:00:43 [ERROR] 2. no linker is defined in the aol.properties file for 'ppc64le.Linux.linker'
> 
> Is that a problem in pljava, or a general java-on-that-platform
> problem?

I think it is probably a Maven-on-that-platform problem.
The nar-maven-plugin does not seem to have any toolchain definition
for "ppc64le.Linux". As far as ppc, I only see "ppc64.AIX" in its
toolchain properties file:

https://github.com/maven-nar/nar-maven-plugin/blob/master/src/main/resources/com/github/maven_nar/aol.properties#L1048

("aol" for the nar-maven-plugin means architecture-OS-linker, not an early
internet service provider.)

PL/Java includes a contributed toolchain properties file for Solaris gcc:
https://github.com/tada/pljava/blob/V1_5_1b2/pljava-so/aol.solaris-gcc.properties

A similar contributed file for ppc64le.Linux should work. It could be
a github pull request.

-Chap