forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit35a5280
committed
Add stack-overflow guards in set-operation planning.
create_plan_recurse lacked any stack depth check. This is not perour normal coding rules, but I'd supposed it was safe because earlierplanner processing is more complex and presumably should eat morestack. But bug #15033 from Andrew Grossman shows this isn't true,at least not for queries having the form of a many-thousand-wayINTERSECT stack.Further testing showed that recurse_set_operations is also capableof being crashed in this way, since it likewise will recurse to thebottom of a parsetree before calling any support functions thatmight themselves contain any stack checks. However, its stackconsumption is only perhaps a third of create_plan_recurse's.It's possible that this particular problem with create_plan_recurse canonly manifest in 9.6 and later, since before that we didn't build a Pathtree for set operations. But having seen this example, I now have nofaith in the proposition that create_plan_recurse doesn't need a stackcheck, so back-patch to all supported branches.Discussion:https://postgr.es/m/20180127050845.28812.58244@wrigleys.postgresql.org1 parent010123e commit35a5280
2 files changed
+6
-0
lines changedLines changed: 3 additions & 0 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
358 | 358 |
| |
359 | 359 |
| |
360 | 360 |
| |
| 361 | + | |
| 362 | + | |
| 363 | + | |
361 | 364 |
| |
362 | 365 |
| |
363 | 366 |
| |
|
Lines changed: 3 additions & 0 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
267 | 267 |
| |
268 | 268 |
| |
269 | 269 |
| |
| 270 | + | |
| 271 | + | |
| 272 | + | |
270 | 273 |
| |
271 | 274 |
| |
272 | 275 |
| |
|
0 commit comments
Comments
(0)