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: 
 <CABaY9E66sBPg2UWVpO+xNZEcM7h5_s6CD0KDj_eUct5Es2xaHA@mail.gmail.com>
References: <20180127050845.28812.58244@wrigleys.postgresql.org>
 <17399.1517083207@sss.pgh.pa.us>
 <CABaY9E6NBuX7H==XtcdLCYNZ4U1EMa=D2mg8q58i0TgPCAOexQ@mail.gmail.com>
 <20359.1517090266@sss.pgh.pa.us>
 <CABaY9E66sBPg2UWVpO+xNZEcM7h5_s6CD0KDj_eUct5Es2xaHA@mail.gmail.com>
Comments: In-reply-to Andrew Grossman <agrossman@gmail.com>
	message dated "Sun, 28 Jan 2018 04:38:36 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <11848.1517120505.1@sss.pgh.pa.us>
Date: Sun, 28 Jan 2018 01:21:45 -0500
Message-ID: <11849.1517120505@sss.pgh.pa.us>
Precedence: bulk

Andrew Grossman <agrossman@gmail.com> writes:
> It looks like the same crash:

Yeah, I agree, create_plan_recurse is at fault there.  Will fix it,
thanks for confirming!

Of course, the "fix" will just result in producing a "stack overflowed"
error instead of dumping core.  There's still the question of why this
case worked for you before and doesn't now.  Seemingly, current code
needs more stack to process this query than 9.5 did.  Is it significantly
more, or were you just unlucky enough to overrun the limit when you'd
not quite done so before?  And if it is significantly more, is there
anything we can reasonably do about that?  These questions remain unclear
at this point.

			regards, tom lane