BUG #3897: plJava dll still doesn't load

On Wed, 23 Jan 2008, David Gradwell wrote:

Bug reference: 3897
PostgreSQL version: 8.3rc2
Operating system: Windows Server 2003
Description: plJava dll still doesn't load
Details:

I've successfully installed plJava on postgres 8.2.6 using Kris Jurka's
version at http://www.ejurka.com/pgsql/pljava/826/. Note that I failed to
get the standard distribution download to work.

8.2.6 will not be repackaged, so the official fix will be in 8.2.7 which
has not yet been scheduled.

I've now tried to get plJava running on 8.3rc2 (having failed on rc1 -
already reported) using the pljava.dll and pljava.jar in the distribution.

I checked with the windows installer guys and they say they've got the
updated pljava in RC2 and have tested it to ensure that it works. What
they put in RC2 is the repackaged pljava for 8.3rc1 I put up here:

http://ejurka.com/pgsql/pljava/83rc1/

So it wouldn't hurt to try the above, but I don't have great hopes that it
will change things for you unless something got lost along the way.

Kris Jurka

On Jan 24, 2008 11:16 AM, Kris Jurka <books@ejurka.com> wrote:

On Wed, 23 Jan 2008, David Gradwell wrote:

Bug reference: 3897
PostgreSQL version: 8.3rc2
Operating system: Windows Server 2003
Description: plJava dll still doesn't load
Details:

I've successfully installed plJava on postgres 8.2.6 using Kris Jurka's
version at http://www.ejurka.com/pgsql/pljava/826/. Note that I failed to
get the standard distribution download to work.

8.2.6 will not be repackaged, so the official fix will be in 8.2.7 which
has not yet been scheduled.

I do intend to re-package 8.2.6, just haven't found the time yet. I
*might* be able to later today.

/D

On Jan 24, 2008 11:50 AM, Dave Page <dpage@postgresql.org> wrote:

On Jan 24, 2008 11:16 AM, Kris Jurka <books@ejurka.com> wrote:

8.2.6 will not be repackaged, so the official fix will be in 8.2.7 which
has not yet been scheduled.

I do intend to re-package 8.2.6, just haven't found the time yet. I
*might* be able to later today.

I managed to squeeze it in between some other stuff. It's on the
server now, and should be generally available for download within 24
hours.

Hiroshi: does the Japanese build need to be rebuilt with the new plJava build?

Regards, Dave

8.2.6 will not be repackaged, so the official fix will be in 8.2.7 which
has not yet been scheduled.

I do intend to re-package 8.2.6, just haven't found the time yet. I
*might* be able to later today.

I managed to squeeze it in between some other stuff. It's on the
server now, and should be generally available for download within 24
hours.

Great news, thanks Dave!

/Magnus

Hi.

----- Original Message -----
From: "Dave Page" <dpage@postgresql.org>

On Jan 24, 2008 11:50 AM, Dave Page <dpage@postgresql.org> wrote:

On Jan 24, 2008 11:16 AM, Kris Jurka <books@ejurka.com> wrote:

8.2.6 will not be repackaged, so the official fix will be in 8.2.7 which
has not yet been scheduled.

I do intend to re-package 8.2.6, just haven't found the time yet. I
*might* be able to later today.

I managed to squeeze it in between some other stuff. It's on the
server now, and should be generally available for download within 24
hours.

Hiroshi: does the Japanese build need to be rebuilt with the new plJava build?

Yeah, It is a very important release version.!
Anyway, I will try hard with problem solution of slony. :-)

Regards,
Hiroshi Saito

On Jan 25, 2008 11:08 AM, David JL Gradwell <David@gradwell.com> wrote:

I also noticed whilst I was doing the original 8.3rc2 install that I could
not specify PL/Java as a language to enable in the default database - see
screenshot.

Ahh - now that's most likely the problem. The installer only enables
the plJava checkbox if it finds a JVM in the path - and if it can't,
most likely the server can't either.

Track down your copy of jvm.dll, add the directory to the system path,
and then restart the machine to ensure that the updated path gets
picked up by PostgreSQL (I'm not sure if just restarting Postgres will
work).

Regards, Dave

Hi Dave,

Thanks for the help. I have now got pljava working fine on 8.3RC2 and have
re-run all my tests against RC2. On a database with a data structure of
100+ tables and about 15 views with extensive (20+ per view) unions the
performance is far better than 8.1 and better than 8.2.6, even on a small
test machine.

Coming back to pljava, I've still had problems with the error messages
(which seem to be the wrong way round!)and am happy to see if I can improve
them for the benefit of others. Specifically:

a) "ERROR: Failed to create Java VM (SQL State is 'XX000')" when
calling sqlj.install_jar actually means that pljava.classpath in
postgresql.conf is either not set or not set correctly and hence pljava.jar
can not be found. pljava.classpath could be defaulted to "C:\Program
Files\PostgreSQL\8.2\share\pljava" in the installation.

b) 'ERROR: could not load library "C:/pljava/pljava.dll": The specified
module could not be found.' on
CREATE FUNCTION sqlj.java_call_handler()
RETURNS language_handler AS 'pljava'
LANGUAGE C;
Means (as you said) that the jvm.dll can not be loaded and that the DOS PATH
doesn't include "C:\Program Files\Java\jdk1.6.0_02\jre\bin\client" or
similar.

I've got the 1.3.0 pljava code into NetBeans IDE and will see if I can find
where these messages arise.

Regards

David

-----Original Message-----
From: Dave Page [mailto:dpage@pgadmin.org]
Sent: 26 January 2008 15:16
To: David JL Gradwell
Cc: Kris Jurka; pgsql-bugs@postgresql.org
Subject: Re: BUG #3897: plJava dll still doesn't load for 8.3RC2

Hi David,

On Jan 26, 2008 12:21 PM, David JL Gradwell <David@gradwell.com> wrote:

Dave,

First of all I have carefully checked my path environment variable. Going
PATH at the command prompt gives:

C:\Documents and Settings\David>path

PATH=C:\Program Files\Java\jdk1.6.0_04;C:\Program

Files\Java\jdk1.6.0_04\jre;C:\pljava;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDO
WS\System32\Wbem

On all my machines, jvm.dll is in:

C:\Program Files\Java\jre1.6.0_02\bin\client

(adjust the version number accordingly of course). When that's in the
path, the installer will let you install plJava. Note though that it
doesn't install the files any differently when the option is greyed
out in the installer - it just doesn't run C:\Program
Files\PostgreSQL\8.3RC2\share\pljava\install.sql in template1. You can
do this at any time afterward though once the path is correct.

Regards, Dave.

On Jan 28, 2008 9:33 AM, David JL Gradwell <David@gradwell.com> wrote:

Hi Dave,

Thanks for the help. I have now got pljava working fine on 8.3RC2 and have
re-run all my tests against RC2. On a database with a data structure of
100+ tables and about 15 views with extensive (20+ per view) unions the
performance is far better than 8.1 and better than 8.2.6, even on a small
test machine.

Good news :-)

Coming back to pljava, I've still had problems with the error messages
(which seem to be the wrong way round!)and am happy to see if I can improve
them for the benefit of others. Specifically:

a) "ERROR: Failed to create Java VM (SQL State is 'XX000')" when
calling sqlj.install_jar actually means that pljava.classpath in
postgresql.conf is either not set or not set correctly and hence pljava.jar
can not be found. pljava.classpath could be defaulted to "C:\Program
Files\PostgreSQL\8.2\share\pljava" in the installation.

I'll leave that one for Kris or one of the other Java guys. I've
written maybe a dozen lines of Java code in my entire life!

b) 'ERROR: could not load library "C:/pljava/pljava.dll": The specified
module could not be found.' on
CREATE FUNCTION sqlj.java_call_handler()
RETURNS language_handler AS 'pljava'
LANGUAGE C;
Means (as you said) that the jvm.dll can not be loaded and that the DOS PATH
doesn't include "C:\Program Files\Java\jdk1.6.0_02\jre\bin\client" or
similar.

Thats a generic messages raised by PostgreSQL when it fails to load a
library - unfortunately I don't think there's not much that can be
done to improve things there, at least without some horribly platform
specific hacks.

Regards, Dave.

Dave & Kris,

I've dug into some of the problems I've been having in a bit more logical
detail.

A useful tool is Dependency Walker http://www.dependencywalker.com/

Try running this against pljava.dll. You will get varying results,
depending on the PATH and whether you have PostgreSQL 8.2 or 8.3 on the
PATH. In any case you will see clearly which dlls have to be on the PATH
and whether they can be seen by the dll loader.

From this we can see that PostreSQL 8.2.6 uses a dll called MSVCR71.dll
whereas PostreSQL 8.3RC2 uses MSVCR80.dll which is not to be found in
C:\WINDOWS\System32 on all my machines ! This seems to stop the pljava.dll
loading.

A couple of links give a useful insight:

http://blogs.gotdotnet.com/mikehall/archive/2005/12/01/498999.aspx

http://www.instant-registry-fixes.org/why-do-i-keep-receiving-msvcr80dll-mis
sing-errors/

From this I deduce that the MSVCR80.dll needs to be distributed in the
PostreSQL distribution for Windows.

As part of my investigation I wrote a small Java program that a potential
plJava user can run if they hit problems. It will give them some clues as
to what to look for ! See attached.

Regards

David Gradwell

-----Original Message-----
From: Dave Page [mailto:dpage@pgadmin.org]
Sent: 28 January 2008 09:43
To: David JL Gradwell
Cc: Kris Jurka; pgsql-bugs@postgresql.org
Subject: Re: BUG #3897: plJava dll still doesn't load for 8.3RC2

On Jan 28, 2008 9:33 AM, David JL Gradwell <David@gradwell.com> wrote:

Hi Dave,

Thanks for the help. I have now got pljava working fine on 8.3RC2 and

have

re-run all my tests against RC2. On a database with a data structure of
100+ tables and about 15 views with extensive (20+ per view) unions the
performance is far better than 8.1 and better than 8.2.6, even on a small
test machine.

Good news :-)

Coming back to pljava, I've still had problems with the error messages
(which seem to be the wrong way round!)and am happy to see if I can

improve

them for the benefit of others. Specifically:

a) "ERROR: Failed to create Java VM (SQL State is 'XX000')" when
calling sqlj.install_jar actually means that pljava.classpath in
postgresql.conf is either not set or not set correctly and hence

pljava.jar

can not be found. pljava.classpath could be defaulted to "C:\Program
Files\PostgreSQL\8.2\share\pljava" in the installation.

I'll leave that one for Kris or one of the other Java guys. I've
written maybe a dozen lines of Java code in my entire life!

b) 'ERROR: could not load library "C:/pljava/pljava.dll": The

specified

module could not be found.' on
CREATE FUNCTION sqlj.java_call_handler()
RETURNS language_handler AS 'pljava'
LANGUAGE C;
Means (as you said) that the jvm.dll can not be loaded and that the DOS

PATH

doesn't include "C:\Program Files\Java\jdk1.6.0_02\jre\bin\client" or
similar.

Thats a generic messages raised by PostgreSQL when it fails to load a
library - unfortunately I don't think there's not much that can be
done to improve things there, at least without some horribly platform
specific hacks.

Regards, Dave.

On Jan 29, 2008 3:33 PM, David JL Gradwell <David@gradwell.com> wrote:

Dave & Kris,

From this I deduce that the MSVCR80.dll needs to be distributed in the
PostreSQL distribution for Windows.

It is - without it, PostgreSQL wouldn't even run (or pgAdmin,
StackBuilder etc for that matter). We distribute the full runtime
package from Microsoft - specifically the Windows Installer merge
module provided with Visual Studio 2005.

The VS2K5 runtimes don't exactly get installed in the mos obvious
places though - for example, on my development machine they're in

c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.DLL

but as long as it's properly installed (which the merge module we use
was specifically designed by Microsoft to do) then it should work OK,
barring other issues such as jvm.dll not being in your path. BTW,
depends.exe will highlight modules that cannot be located in a fairly
obvious way - but beware; you're probably running it with a different
path than Postgres has when started by the SCM, and it won't
necessarily find libraries that Postgres has other ways to locate (for
example ones in the Postgres libdir).

Regards, Dave.