Re: BUG #15033: Segmentation fault running a query
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Grossman <agrossman@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2018-01-27T21:57:46Z
Lists: pgsql-bugs
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
Commits
-
Add stack-overflow guards in set-operation planning.
- e194f13838a5 9.5.11 landed
- c03fc84626be 9.3.21 landed
- 4e9fb4bfe2e3 9.6.7 landed
- 35a528062cc8 11.0 landed
- 1b2a3860d3ea 10.2 landed
- 06efc5cf53b9 9.4.16 landed
-
Improve performance in freeing memory contexts
- 25c539233044 9.6.0 cited