On Sat, Dec 16, 2017 at 10:13 PM, Andreas Seltenreich <seltenre...@gmx.de> wrote: > Amit Kapila writes: > >> This seems to be another symptom of the problem related to >> es_query_dsa for which Thomas has sent a patch on a different thread >> [1]. After applying that patch, I am not able to see the problem. I >> think due to the wrong usage of dsa across nodes, it can lead to >> sending some wrong values for params to workers. >> >> [1] - >> https://www.postgresql.org/message-id/CAEepm%3D0Mv9BigJPpribGQhnHqVGYo2%2BkmzekGUVJJc9Y_ZVaYA%40mail.gmail.com > > while my posted recipe is indeed inconspicuous with the patch applied, > It seems to have made matters worse from the sqlsmith perspective: > Instead of one core dump per hour I get one per minute. Sample > backtrace below. I could not find a recipe yet to reproduce these > (beyond starting sqlsmith). > > regards, > Andreas > > 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? 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. -- Thomas Munro http://www.enterprisedb.com
