RE: [Pljava-dev] odd error with 1.5.0-snapshot

Whatever is the offical answer by distrib maintainers, José's question seems very legit.
While you guys are struggling for PL/Java to be integrated in distribs, "we" are losing sysadmins which have a harder time every day to justify that the project is still alive.
Why ? Because they have to spend an awful lot of time making it work on new releases of PG.
Guys ! Do you have any idea how "alien" it is to set up a proper maven/compiler environment when you're not a field proven developer ? More even under Windows ?

Why do "we" not at least offer binaries for Windows/Linux, 32/64. Having had to build PL/Java by the past, I don't think I remember there's any external dependency apart from the PG version. But if I'm wrong, then let's just build the .so/.dll static !

To conclude, as far as I understand it, José's request means that, the longer there is no binaries available, the more the user base will shrink with doubts regarding the long term legitimacy of this project. Which is totally unfair in view of you guys amazing (and successful) job to give it a second breath !

Just my 2cts anyways.

Frédéric.

-----Message d'origine-----
De : Pljava-dev [mailto:pljava-dev-bounces(at)lists(dot)pgfoundry(dot)org] De la part de Chapman Flack
Envoyé : mercredi 3 février 2016 23:16
À : pljava-dev(at)lists(dot)pgfoundry(dot)org
Objet : Re: [Pljava-dev] odd error with 1.5.0-snapshot

On 02/03/2016 02:24 PM, John R Pierce wrote:
> curious if you have any hints about what that SQLException means.
> java.sql.SQLException: An attempt was made to call a PostgreSQL
> backend function after an elog(ERROR) had been issued

Ok, what it ostensibly means is: the code had, in the past, made some call into PostgreSQL that ereport()ed an ERROR. That turns into an SQLException in PL/Java (not the one we're looking at here, this had to have happened earlier). Perhaps the code had a try/catch block and caught that exception, and now it wants to proceed and do more stuff.

Trouble is, whenever an ERROR has been thrown from a call into PostgreSQL, we don't know what possibly gronkled state the transaction has been left in, and for the remainder of this PL/Java function call, no more access to PostgreSQL is going to be allowed.
That's what produced *this* SQLException, at the point where the code seems to be going ahead and setting a parameter in a prepared statement.

If you are writing PL/Java code that does want to catch an exception thrown from PostgreSQL, recover and proceed to do more stuff, there is one way to do that. You have to use sp = conn.setSavepoint() in advance of where the exception might be thrown, and
conn.releaseSavepoint(sp) in the normal case where your call is successful. In the catch block if an exception has been thrown, use conn.rollback(sp) to put the transaction back into a known non-gronkled state and now you can proceed to make more calls.

That was the official answer. A different interesting question might be, what was the earlier exception that had been thrown and caught, and why was it thrown in this case if the same code had been in use before? They might want to redo the test with client_min_messages or log_min_messages (or both) set to DEBUG2 or higher.

-Chap

_______________________________________________
Pljava-dev mailing list
Pljava-dev(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev