From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Grossman <agrossman@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15033: Segmentation fault running a query
In-reply-to: 
 <CABaY9E6NBuX7H==XtcdLCYNZ4U1EMa=D2mg8q58i0TgPCAOexQ@mail.gmail.com>
References: <20180127050845.28812.58244@wrigleys.postgresql.org>
 <17399.1517083207@sss.pgh.pa.us>
 <CABaY9E6NBuX7H==XtcdLCYNZ4U1EMa=D2mg8q58i0TgPCAOexQ@mail.gmail.com>
Comments: In-reply-to Andrew Grossman <agrossman@gmail.com>
	message dated "Sat, 27 Jan 2018 20:06:48 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20358.1517090266.1@sss.pgh.pa.us>
Date: Sat, 27 Jan 2018 16:57:46 -0500
Message-ID: <20359.1517090266@sss.pgh.pa.us>
Precedence: bulk

Andrew Grossman <agrossman@gmail.com> writes:
> I will follow-up with a stack trace. In the meantime, a more accessible
> version of the reproduction script has been placed at the following address:
> https://fleetinventory.com/media/static/pg10crash.sql

Thanks.  I pulled that down, and while it didn't reproduce for me
immediately, some fooling with the postmaster's "ulimit -s" setting
eventually produced a crash in the recursion in create_plan_recurse(),
which indeed lacks a check_stack_depth call and should have one.
But I wonder whether that's the identical crash site you're seeing.
This query is going to result in deep recursion in quite a few places,
and there might be other ones that need protection.  The amount of
stack consumed per recursion level could vary across machines, so
that the deepest stack growth might not be at the same place for
everybody.  (I'm actually rather surprised to see create_plan_recurse
be the weakest link --- I'd have figured that earlier planner phases
would consume more stack per setop.)

			regards, tom lane