On Sun, Dec 17, 2017 at 12:26 PM, Andreas Seltenreich <seltenre...@gmx.de> wrote: > Thomas Munro writes: > >> On Sat, Dec 16, 2017 at 10:13 PM, Andreas Seltenreich >> <seltenre...@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
