References: <56B253DA.2090003@hogranch.com>
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <56B26010.2010207@anastigmatix.net>
Date: Wed, 3 Feb 2016 15:16:16 -0500
MIME-Version: 1.0
In-Reply-To: <56B253DA.2090003@hogranch.com>
Subject: Re: [Pljava-dev] odd error with 1.5.0-snapshot
Content-Type: text/plain; charset="us-ascii"

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@lists.pgfoundry.org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev