Re: BUG #15033: Segmentation fault running a query

I wrote:
> Andrew Grossman <agrossman(at)gmail(dot)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