On 10/25/16 18:56, Chapman Flack wrote: > If pooled, and tied to the backend that started them, do they need > to do anything special to detect when the leader has executed > SET ROLE or SET SESSION AUTHORIZATION?
Let me guess ... such information is *not* synchronized across workers, and that'd be why the manual says "functions must be marked PARALLEL RESTRICTED if they access ... client connection state ..."? That's probably a resounding 'no' for declaring any PL/Java function SAFE, then. And if changing "the transaction state even temporarily (e.g. a PL/pgsql function which establishes an EXCEPTION block to catch errors)" is enough to require UNSAFE, then it may be that RESTRICTED is off limits too, as there are places PL/Java does that internally. I take it that example refers not to just any use of PG_TRY/PG_CATCH, but only to those uses where an internal subtransaction is used to allow execution to continue? If a person writes a function in some language (SQL, for example), declares it PARALLEL SAFE but is lying because it calls another function (in Java, say) that is PARALLEL UNSAFE or RESTRICTED, does PostgreSQL detect or prevent that, or is it just considered an unfortunate mistake by the goofball who declared the first function safe? And if that's not already prevented, could it be worth adding code in the PL/Java call handler to detect such a situation and make sure it ends in a meaningful ereport and not something worse? -Chap -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers