Re: IMMUTABLE and PARALLEL SAFE function markings - Mailing list pgsql-hackers

From Tom Lane
Subject Re: IMMUTABLE and PARALLEL SAFE function markings
Date
Msg-id 5704.1543292502@sss.pgh.pa.us
Whole thread Raw
In response to Re: IMMUTABLE and PARALLEL SAFE function markings  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: IMMUTABLE and PARALLEL SAFE function markings
Re: IMMUTABLE and PARALLEL SAFE function markings
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Nov 26, 2018 at 8:49 PM Andrew Gierth
> <andrew@tao11.riddles.org.uk> wrote:
>> I'm a bit more concerned by the fact that inlining the function isn't
>> affecting the parallel safety of the query - the fact that parallel
>> safety is being checked prior to inlining means that if inlining
>> *introduces* a parallel hazard, it will go unnoticed?

> If a function is marked parallel-safe but internally calls
> parallel-restricted or parallel-unsafe functions, it wasn't really
> parallel-safe in the first place.  So I think that if inlining
> introduces a parallel hazard, the user has mislabeled some functions
> and any resulting injury is self-inflicted.

Hm.  We intentionally allow SQL functions to be marked as less mutable
than their internals, because sometimes that's useful for tricking
the planner.  However, IIRC we don't inline when we see that's the
case.  Maybe there needs to be a similar restriction for parallelism
markings.

Alternatively, could we postpone the parallelism checks till after
function inlining?  Do we even make any before that?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: IMMUTABLE and PARALLEL SAFE function markings
Next
From: Robert Haas
Date:
Subject: Re: IMMUTABLE and PARALLEL SAFE function markings