On Sat, Feb 25, 2017 at 5:12 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > Sure, but that should only happen if the function is *not* declared as > parallel safe (aka in parallel safe functions, we should not generate > parallel plans).
So basically we want to put a restriction that parallel-safe function can not use the parallel query? This will work but it seems too restrictive to me. Because by marking function parallel safe we enable it to be used with the outer parallel query that is fine. But, that should not restrict the function from using the parallel query if it's used with the other outer query which is not having the parallel plan(or function is executed directly). > >> So I think we >> may need some check during execution time as well? >> > > Right, I also think we need some mechanism where if the user has not > marked the parallel safe functions appropriately, then such executions > should result in error. For example, if parallel-safe function calls > a parallel-unsafe function which contains either write statement or > statement that could generate a parallel plan, then we should not > allow execution of such queries. We already have safeguard checks at > most places like write statements (see heap_update), however, I think > we need a similar check in ExecGather. How about we allow parallel-safe functions to create a parallel plan but whenever it's used from an unsafe place i.e. already in the parallel mode we don't allow to launch worker? -- Regards, Dilip Kumar 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
