From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
cc: Robert Haas <robertmhaas@gmail.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Oddity with parallel safety test for scan/join target in
 grouping_planner
In-reply-to: <5C85ED63.8000805@lab.ntt.co.jp>
References: <5C75303E.8020303@lab.ntt.co.jp>
 <CA+TgmobmV=Zw2OEJKUorJe=e+_fCzsvYErR6tXxTjCzK45x9RQ@mail.gmail.com>
 <5C7908B9.5070407@lab.ntt.co.jp> <24818.1552077419@sss.pgh.pa.us>
 <5C85DC65.2050409@lab.ntt.co.jp> <32401.1552277190@sss.pgh.pa.us>
 <5C85ED63.8000805@lab.ntt.co.jp>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
	message dated "Mon, 11 Mar 2019 14:08:51 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1961.1552281261.1@sss.pgh.pa.us>
Date: Mon, 11 Mar 2019 01:14:21 -0400
Message-ID: <1962.1552281261@sss.pgh.pa.us>
Precedence: bulk

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> (2019/03/11 13:06), Tom Lane wrote:
>> Is that the only possible outcome?  Per Robert's summary quoted above,
>> it seems like it might be possible for the code to decide that the final
>> scan/join target to be parallel safe when it is not, leading to outright
>> wrong answers or query failures.

> Maybe I'm missing something, but I think that if the final scan/join 
> target is not parallel-safe, then the grouping target would not be 
> parallel-safe either, by the construction of the two targets, so I don't 
> think that we have such a correctness issue.

Seems to me it's the other way around: the final target would include
all functions invoked in the grouping target plus maybe some more.
So a non-parallel-safe grouping target implies a non-parallel-safe
final target, but not vice versa.

Possibly the summary had it backwards and the actual code bug is
inferring things in the safe direction, but I'm too tired to double
check that right now ...

			regards, tom lane