PL/Java is a free add-on module that brings Java™ Stored Procedures, Triggers, Functions, Aggregates, Operators, Types, etc., to the PostgreSQL™ backend.
The java_thread_pg_entry=allow mode is the one longest supported in PL/Java, and it ought eventually to be phased out, as its way of serializing threads' access to PG is fussy, and involves quite unconvincing manipulation of PG internal variables used for detecting excessive stack use. A better mode, not yet implemented, would be to forever allow only the original PG thread to enter PG; on entry to PL/Java, it should dispatch the Java work quickly onto some other thread and then wait as a single-thread executor service to handle doInPG requests, until completion of the thread handling the work.
However, until that better mode is implemented, allow mode ought to be usable. Issue #471 identified a bug in Portal.close causing it to fail depending on the thread invoking it.
Although any such use of Portal.close could be affected, the issue was reported in Java class loading. A library that uses threads may need to enter PL/Java's classloader on an arbitrary thread; if that doesn't work, there really aren't ways to restructure the application as a workaround that aren't impractically onerous.
The failure also gave unhelpful diagnostics, in which the triggering event (failure of a PG stack depth check) would be caught and unreported, leaving a later entry into PG to fail with "An attempt was made to call a PostgreSQL backend function after an elog(ERROR)", and that would be the mysterious cause of a ClassNotFoundException.
This PR fixes what seems to be the only instance of the buggy coding pattern.
The
java_thread_pg_entry=allowmode is the one longest supported in PL/Java, and it ought eventually to be phased out, as its way of serializing threads' access to PG is fussy, and involves quite unconvincing manipulation of PG internal variables used for detecting excessive stack use. A better mode, not yet implemented, would be to forever allow only the original PG thread to enter PG; on entry to PL/Java, it should dispatch the Java work quickly onto some other thread and then wait as a single-thread executor service to handledoInPGrequests, until completion of the thread handling the work.However, until that better mode is implemented,
allowmode ought to be usable. Issue #471 identified a bug inPortal.closecausing it to fail depending on the thread invoking it.Although any such use of
Portal.closecould be affected, the issue was reported in Java class loading. A library that uses threads may need to enter PL/Java's classloader on an arbitrary thread; if that doesn't work, there really aren't ways to restructure the application as a workaround that aren't impractically onerous.The failure also gave unhelpful diagnostics, in which the triggering event (failure of a PG stack depth check) would be caught and unreported, leaving a later entry into PG to fail with "An attempt was made to call a PostgreSQL backend function after an
elog(ERROR)", and that would be the mysterious cause of aClassNotFoundException.This PR fixes what seems to be the only instance of the buggy coding pattern.