Request help on backup and recovery a database with Pl / java stored procedures about pljava HOT 2 CLOSED

Keeping this issue (of the original three) open as a reminder there could be better documentation of how to backup/restore, and maybe better error messages from classloading/method resolution.

From the details above, it does not appear the OP had a problem related to typemap_entry. It seems more likely that the proper jar entries were not found or the right methods could not be found within them. It would have been helpful to know what was in jar_repository and jar_entry. Looking at the code where that message is produced, it seems there must have been a class, but the method was not found. Perhaps there was a version mismatch in the classes loaded?

It is possible that the JNI getStaticMethodID method creates an exception that would contain additional information not currently included in the message PL/Java reports. If so, perhaps the message could be made more helpful.

from pljava.

It appears the original reporter will not be back. There was probably not a PL/Java problem here, and it will be hard to get more information about the reporter's situation. Some response to the issues I can see may help future readers who see this ticket.

The Unable to find static method messages would have been accompanied by the details of the underlying Java exceptions, but those details would have gone to stderr directly, instead of through the PostgreSQL logging system. I am not sure (for Windows) how to view the messages that were printed to stderr, but it will be helpful in troubleshooting. Future developments in the logging infrastructure should improve this.

PL/Java itself was operating, ruling out problems with the dynamic library path or pljava.classpath. However, pljava.classpath only needed to have pljava.jar in it. The jdbc jar is not needed (for any purpose in PL/Java, unless the reporter specifically wrote Java code using it to open other database connections), and the Mission.jar only needed to be installed with sqlj.install_jar, not to be in the pljava.classpath (which is only where PL/Java needs to find its own code).

Conversely, sqlj.install_jar did not need to be done for pljava.jar, only for Mission.jar.

Those are minor misconfigurations that did not cause the reported problem, but clarifying them may save someone else a bit of time. Whatever was happening for the poster will not be known without more reported detail.

Therefore, closing.

from pljava.