Re: BUG #15033: Segmentation fault running a query
От | Tom Lane |
---|---|
Тема | Re: BUG #15033: Segmentation fault running a query |
Дата | |
Msg-id | 20359.1517090266@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15033: Segmentation fault running a query (Andrew Grossman <agrossman@gmail.com>) |
Ответы |
Re: BUG #15033: Segmentation fault running a query
|
Список | 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
В списке pgsql-bugs по дате отправления: