Amit Kapila wrote:
> On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich <>
> 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      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to