From: Tom Lane <tgl@sss.pgh.pa.us>
To: James Coleman <jtc331@gmail.com>
cc: luis.roberto@siscobra.com.br,
 pgsql-bugs <pgsql-bugs@lists.postgresql.org>,
        "alan.formagi" <alan.formagi@siscobra.com.br>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>
Subject: Re: segfault with incremental sort
In-reply-to: 
 <CAAaqYe--qpnBOUiqnHSAc71K2HpXetnGedRAX0Z04zx=Y0ExHA@mail.gmail.com>
References: <622580997.37108180.1604080457319.JavaMail.zimbra@siscobra.com.br>
 <102089.1604082122@sss.pgh.pa.us>
 <541187747.37582276.1604086719237.JavaMail.zimbra@siscobra.com.br>
 <107029.1604087483@sss.pgh.pa.us>
 <1673261949.37800156.1604090102715.JavaMail.zimbra@siscobra.com.br>
 <1807748588.37862034.1604091799640.JavaMail.zimbra@siscobra.com.br>
 <136656.1604092024@sss.pgh.pa.us>
 <1779929796.39206557.1604407053112.JavaMail.zimbra@siscobra.com.br>
 <924226.1604422326@sss.pgh.pa.us>
 <CAAaqYe--qpnBOUiqnHSAc71K2HpXetnGedRAX0Z04zx=Y0ExHA@mail.gmail.com>
Comments: In-reply-to James Coleman <jtc331@gmail.com>
	message dated "Tue, 03 Nov 2020 13:35:30 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <961141.1604429292.1@sss.pgh.pa.us>
Date: Tue, 03 Nov 2020 13:48:12 -0500
Message-ID: <961142.1604429292@sss.pgh.pa.us>
Precedence: bulk

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