On Wed, Apr 21, 2021 at 8:12 AM tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> wrote: > > From: Tom Lane <t...@sss.pgh.pa.us> > > [ raised eyebrow... ] I find it very hard to understand why that would > > be necessary, or even a good idea. Not least because there's no spare > > room there; you'd have to incur a substantial enlargement of the > > array to add another flag. But also, that would indeed lock down > > the value of the parallel-safety flag, and that seems like a fairly > > bad idea. > > You're right, FmgrBuiltins is already fully packed (24 bytes on 64-bit > machines). Enlarging the frequently accessed fmgr_builtins array may wreak > unexpectedly large adverse effect on performance. > > I wanted to check the parallel safety of functions, which various objects > (data type, index, trigger, etc.) come down to, in FunctionCallInvoke() and > other few places. But maybe we skip the check for built-in functions. > That's a matter of where we draw a line between where we check and where we > don't. >
IIUC, the idea here is to check for parallel safety of functions at someplace in the code during function invocation so that if we execute any parallel unsafe/restricted function via parallel worker then we error out. If so, isn't it possible to deal with built-in and non-built-in functions in the same way? I think we want to have some safety checks for functions as we have for transaction id in AssignTransactionId(), command id in CommandCounterIncrement(), for write operations in heap_prepare_insert(), etc. Is that correct? -- With Regards, Amit Kapila.
