Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader
Date
Msg-id 12751.1461937508@sss.pgh.pa.us
Whole thread Raw
In response to Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich <seltenreich@gmx.de>
> wrote:
>> tonight's sqlsmith run yielded another core dump:
>> 
>> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
>> "proc.c", Line: 1787)
>> 
>> I couldn't identifiy a query for it though: debug_query_string is empty.
>> 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 execute
> 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.

> It will
> be helpful if you can find the offending query or plan corresponding to it?

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", but it might be
worth copying over the full query from the parent side.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: UNION ALL - Var attno
Next
From: Andrew Dunstan
Date:
Subject: Re: pgsql: Support building with Visual Studio 2015