Re: [bug?] Missed parallel safety checks, and wrong parallel safety - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Date
Msg-id 756027.1619012086@sss.pgh.pa.us
Whole thread Raw
In response to Re: [bug?] Missed parallel safety checks, and wrong parallel safety  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: [bug?] Missed parallel safety checks, and wrong parallel safety  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Re: [bug?] Missed parallel safety checks, and wrong parallel safety  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Wed, Apr 21, 2021 at 8:12 AM tsunakawa.takay@fujitsu.com
> <tsunakawa.takay@fujitsu.com> wrote:
>> From: Tom Lane <tgl@sss.pgh.pa.us>
>>> [ raised eyebrow... ]  I find it very hard to understand why that would
>>> be necessary, or even a good idea.

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

Yeah, one of the reasons I doubt this is a great idea is that you'd
still have to fetch the pg_proc row for non-built-in functions.

The obvious place to install such a check is fmgr_info(), which is
fetching said row anyway for other purposes, so it's really hard to
see how adding anything to FmgrBuiltin is going to help.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Table refer leak in logical replication
Next
From: Honza Horak
Date:
Subject: Re: Do we work with LLVM 12 on s390x?