> >>> I'm curious. The FmgrBuiltin struct includes the "strict" flag, so > >>> that would "lock down the value" of the strict flag, wouldn't it? > > >> It does, but that's much more directly a property of the function's C > >> code than parallel-safety is. > > > I'm not sure I agree with that, but I think having the "strict" flag > > in FmgrBuiltin isn't that nice either. > > Yeah, if we could readily do without it, we probably would. But the function > call mechanism itself is responsible for implementing strictness, so it *has* > to > have that flag available.
So, If we do not want to lock down the parallel safety of built-in functions. It seems we can try to fetch the proparallel from pg_proc for built-in function in fmgr_info_cxt_security too. To avoid recursive safety check when fetching proparallel from pg_proc, we can add a Global variable to mark is it in a recursive state. And we skip safety check in a recursive state, In this approach, parallel safety will not be locked, and there are no new members in FmgrBuiltin. Attaching the patch about this approach [0001-approach-1]. Thoughts ? I also attached another approach patch [0001-approach-2] about adding parallel safety in FmgrBuiltin, because this approach seems faster and we can combine some bool member into a bitflag to avoid enlarging the FmgrBuiltin array, though this approach will lock down the parallel safety of built-in function. Best regards, houzj
0002-fix-testcase-with-wrong-parallel-safety-flag.patch
Description: 0002-fix-testcase-with-wrong-parallel-safety-flag.patch
0001-approach-1-check-parallel-safety-in-fmgr_info_cxt_se.patch
Description: 0001-approach-1-check-parallel-safety-in-fmgr_info_cxt_se.patch
0001-approach-2-check-parallel-safety-in-fmgr_info_cxt_se.patch
Description: 0001-approach-2-check-parallel-safety-in-fmgr_info_cxt_se.patch
