On Fri, Apr 29, 2016 at 7:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapil...@gmail.com> writes:
> > On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich <
> > wrote:
> >> tonight's sqlsmith run yielded another core dump:
> >>
> >> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))",
> >> "proc.c", Line: 1787)
> >>
> >> I couldn't identifiy a query for it though: debug_query_string is
> >> Additionally, the offending query was not reported in the error context
> >> as it typically is for non-parallel executor crashes.
> > From callstack below, it is clear that the reason for core dump is that
> > Gather node is pushed below another Gather node which makes worker
> > the Gather node.  Currently there is no support in workers to launch
> > another workers and ideally such a plan should not be generated.
> It might not be intentional.  The bug we identified from Andreas' prior
> report could be causing this: once a GatherPath's subpath has been freed,
> that palloc chunk could be recycled into another GatherPath, or something
> with a GatherPath in its substructure, leading to a plan of that shape.

Yes, thats one possibility.

> > It will
> > be helpful if you can find the offending query or plan corresponding to
> I presume the lack of debug_query_string data is because nothing is
> bothering to set debug_query_string in a worker process.  Should that be
> remedied?  At the very least set it to "worker process",

Currently for the purpose of query descriptor in worker process, we are
using "<parallel_query>" (refer function ExecParallelGetQueryDesc()), so
that seems to be a better choice.

> but it might be
> worth copying over the full query from the parent side.

That would amount to couple of extra cycles considering we need to do it
for each worker, but OTOH it might be a useful debugging information in the
cases as reported in this thread.  Do you see any broader use of passing
query string to worker?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Reply via email to