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

From Alvaro Herrera
Subject Re: [sqlsmith] Failed assertion in BecomeLockGroupLeader
Date
Msg-id 20160429114039.GA126090@alvherre.pgsql
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
List pgsql-hackers
Amit Kapila wrote:
> On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich <seltenreich@gmx.de>
> wrote:

> > 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 will
> be helpful if you can find the offending query or plan corresponding to it?

So I suppose the PID of the process starting the workers should be in
the stack somewhere.  With that one should be able to attach to that
process and get another stack trace.  I'm curious on whether you would
need to have started the server with "postgres -T" in order to be able
to get a coordinated code dump from both processes.  The
debug_query_string would be found in the leader, I suppose.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Typo
Next
From: Andrew Dunstan
Date:
Subject: Re: VS 2015 support in src/tools/msvc