On Wed, Oct 26, 2016 at 7:39 AM, Chapman Flack <chap@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
