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: <11849.1517120505@sss.pgh.pa.us>
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>
 <11849.1517120505@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 28 Jan 2018 01:21:45 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28886.1517167973.1@sss.pgh.pa.us>
Date: Sun, 28 Jan 2018 14:32:53 -0500
Message-ID: <28887.1517167973@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> 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.

I've pushed a fix for that, and also recurse_set_operations which proved
to also be capable of causing a crash at some stack sizes.

> 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.

It seems that the direct cause of the change is that we now generate a
Path representation of a setop tree, where we didn't before.  The Path
representation is much deeper than the setop tree --- about three
nested Path nodes per setop step --- and it's the deeper recursion
involved in processing that that causes the extra stack demand.
So I'm afraid there's little to be done about it.

On the bright side, I find that with sufficient stack, current code runs
this query in about 4 seconds where 9.5 took 95 seconds.  Seems to be
thanks to commit 25c539233 ("Improve performance in freeing memory
contexts").

			regards, tom lane