James Coleman <jtc331@gmail.com> writes:
> On Tue, Nov 3, 2020 at 11:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So, not only do we need to be thinking about volatility while checking
>> whether IncrementalSort is possible, but also parallel-safety.
> This is part of why I lean towards guessing it applies to regular sort
> also (though haven't confirmed that): the new volatility (and if
> volatile, then "expression is in target" checks just mirror existing
> code pre-incremental sort.
It's certainly possible that the bug exists for non-incremental sort
but previously we'd not try to generate a plan that tripped over it.
Anyway I do not recall seeing code that would specifically check for
this. I think that, to the extent we've avoided it, it's because the
sort key would normally be part of the reltarget list for some relation
that would thereby get marked non-parallel-safe. Maybe the DISTINCT
sort key never ends up in any reltarget list?
> I also noticed that the incremental sort plan posted earlier has
> multiple Gather Merge nodes; that's not what I would have expected,
> but maybe I'm missing something.
Hm. There is only one Gather Merge in the repro case.
regards, tom lane
