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: Sat, 27 Jan 2018 16:57:46 -0500
Message-ID: <20359.1517090266@sss.pgh.pa.us> (raw)
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>
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
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: <20359.1517090266@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