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
> 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

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:

Reply via email to