On Sun, Dec 17, 2017 at 12:26 PM, Andreas Seltenreich
<seltenreich@gmx.de> wrote:
> Thomas Munro writes:
>
>> On Sat, Dec 16, 2017 at 10:13 PM, Andreas Seltenreich
>> <seltenreich@gmx.de> wrote:
>>> Core was generated by `postgres: smith regression [local] SELECT '.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0 gather_getnext (gatherstate=0x555a5fff1350) at nodeGather.c:283
>>> 283 estate->es_query_dsa = gatherstate->pei->area;
>>> #1 ExecGather (pstate=0x555a5fff1350) at nodeGather.c:216
>>
>> Hmm, thanks. That's not good. Do we know if gatherstate->pei is
>> NULL, or if it's somehow pointing to garbage?
>
> It was NULL on all the coredumps I looked into. Below[1] is a full
> gatherstate.
>
>> Not sure how either of those things could happen, since we only set it
>> to NULL in ExecShutdownGather() after which point we shouldn't call
>> ExecGather() again, and any MemoryContext problems with pei should
>> have caused problems already without this patch (for example in
>> ExecParallelCleanup). Clearly I'm missing something.
>
> FWIW, all backtraces collected so far are identical for the first nine
> frames. After ExecProjectSet, they are pretty random executor innards.
Oh, right. We only create pei if (gather->num_workers > 0 &&
estate->es_use_parallel_mode), so I need to teach that patch that pei
may be NULL. I'll go and post a new version like that over on the
other thread.
--
Thomas Munro
http://www.enterprisedb.com