On Wed, Oct 26, 2016 at 7:39 AM, Chapman Flack <c...@anastigmatix.net> wrote: > 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 ..."? >
All the GUCs are synchronised between leader and worker backends. > 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? > No, we don't detect that explicitly before initiating parallelism, however there are checks in code which will report error if you do something unsafe in worker, example perform any write operation in worker. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
