Re: PARALLEL SAFE/UNSAFE question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Satoshi Nagayasu <snaga(at)uptime(dot)jp>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PARALLEL SAFE/UNSAFE question
Date: 2016-07-07 17:29:43
Message-ID: 21680.1467912583@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Satoshi Nagayasu <snaga(at)uptime(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-07-07 17:51:46 Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)
Previous Message Fujii Masao 2016-07-07 17:26:42 Re: EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information.