Обсуждение: PARALLEL SAFE/UNSAFE question

Hi all,

I was trying writing my own parallel aggregation functions on 9.6beta2.
During that, we found a bit confusing behavior with SAFE/UNSAFE options.

Once a PARALLEL UNSAFE function f1_unsafe() is wrapped by
a PARALLEL SAFE function f1_safe_unsafe(), calling f1_safe_unsafe()
produces a parallel execution plan despite it implicitly calls
the UNSAFE FUNCTION f1_unsafe().

Is this intentional?

Please take a look at our example here:
https://gist.github.com/snaga/362a965683fb2581bc693991b1fcf721

According to the manual[1], it is described as:

> the presence of such a function in an SQL statement forces a serial execution plan.

so, I expected that calling UNSAFE functions should produce
a non-parallel execution plan even wrapped in SAFE functions.

Is this a sort of limitations? Is this working correctly as we expected?

Regards,

[1] https://www.postgresql.org/docs/9.6/static/sql-createfunction.html
-- 
Satoshi Nagayasu <snaga@uptime.jp>

Satoshi Nagayasu <snaga@uptime.jp> writes:
> I was trying writing my own parallel aggregation functions on 9.6beta2.
> During that, we found a bit confusing behavior with SAFE/UNSAFE options.

> Once a PARALLEL UNSAFE function f1_unsafe() is wrapped by
> a PARALLEL SAFE function f1_safe_unsafe(), calling f1_safe_unsafe()
> produces a parallel execution plan despite it implicitly calls
> the UNSAFE FUNCTION f1_unsafe().

> Is this intentional?

Yes.  If you mismark the parallel safety of your functions, the
consequences are on your own head.  The system can't be expected to
look inside functions to figure out what their actual behavior is.
(See halting problem.)

As things stand, we actually trust the parallel safety marking of
an aggregate itself, though in principle we could look at the markings
of the component functions instead.  Again, the expectation is that
the programmer will take care with safety markings.
        regards, tom lane