Re: segfault with incremental sort

James Coleman <jtc331(at)gmail(dot)com> writes:
> On Tue, Nov 3, 2020 at 11:52 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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