Re: IMMUTABLE and PARALLEL SAFE function markings

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Hm. We intentionally allow SQL functions to be marked as less
>  Tom> mutable than their internals, because sometimes that's useful for
>  Tom> tricking the planner. However, IIRC we don't inline when we see
>  Tom> that's the case. Maybe there needs to be a similar restriction for
>  Tom> parallelism markings.

> Well, that doesn't help since not inlining the function doesn't prevent
> it from being called in parallel mode.

In the mutability case, our take on this is "you lied, so it's your
problem if you get the wrong answer".  I'd be inclined to take the
same view in the parallelism case, except for the possibility that
forcing a parallel-unsafe function to be executed in a parallel
worker could lead to a crash.  (This gets back to my point about
implementation details --- we don't know exactly why a function
is marked parallel unsafe, and it could be that it really positively
Doesn't Work in a worker, whereas there's not a similar issue with
respect to not-as-immutable-as-claimed functions.)

However ... if that's possible, then we have a security-ish issue
here, because it's not hard at all to ensure that a SQL function
*won't* be inlined.  So somebody who was intent on crashing a
parallel worker could easily exploit a vulnerable function, inlining
or no: just wrap it in a mislabeled SQL wrapper.

Maybe the only real answer is that we need higher standards about
how badly a parallel-unsafe function can mess up.  Or a lower-level
test that prevents one from being called in a worker, independently
of what the planner thought.

> On second thoughts the problem actually isn't directly to do with
> inlining at all. The problem is that in the presence of polymorphism,
> the function author can't have any confidence in setting any function as
> parallel-safe, since they can't know what the actual functions are that
> will be called at run time.

We've encountered similar issues with respect to the mutability of
datatype I/O functions, and resolved them via a messy compromise:
I/O functions aren't allowed to be volatile, while callers aren't
allowed to assume they're immutable.  Not sure if such a concept
would help here.

            regards, tom lane