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
Date: Sun, 28 Jan 2018 14:32:53 -0500
Message-ID: <28887.1517167973@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, agrossman@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15033: Segmentation fault running a query
In-Reply-To: <28887.1517167973@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox