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 525693.1618930183@sss.pgh.pa.us
Whole thread Raw
In response to Re: [bug?] Missed parallel safety checks, and wrong parallel safety  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses RE: [bug?] Missed parallel safety checks, and wrong parallel safety  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List pgsql-hackers
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
> On Tue, Apr 20, 2021 at 2:23 PM tsunakawa.takay@fujitsu.com
> <tsunakawa.takay@fujitsu.com> wrote:
>> https://www.postgresql.org/docs/devel/xaggr.html
>>
>> "Worth noting also is that for an aggregate to be executed in parallel, the aggregate itself must be marked PARALLEL
SAFE.The parallel-safety markings on its support functions are not consulted." 

> IMO, the reason for not checking the parallel safety of the support
> functions is that the functions themselves can have whole lot of other
> functions (can be nested as well) which might be quite hard to check
> at the planning time. That is why the job of marking an aggregate as
> parallel safe is best left to the user.

Yes.  I think the documentation is perfectly clear that this is
intentional; I don't see a need to change it.

>> Should we add a member for parallel safety in fmgr_builtins[], and disallow ALTER FUNCTION to change the parallel
safetyof builtin UDFs? 

No.  You'd have to be superuser anyway to do that, and we're not in the
habit of trying to put training wheels on superusers.

Don't have an opinion about the other points yet.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "could not find pathkey item to sort" for TPC-DS queries 94-96
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_amcheck option to install extension