Re: BUG #15033: Segmentation fault running a query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Grossman <agrossman(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15033: Segmentation fault running a query
Date: 2018-01-27 21:57:46
Message-ID: 20359.1517090266@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-01-27 22:28:02 BUG #15034: date value inserts
Previous Message Andrew Grossman 2018-01-27 20:06:48 Re: BUG #15033: Segmentation fault running a query