Re: Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter |
| Дата | |
| Msg-id | cfc37fd8-e1e7-4590-a81f-71e95b035ae0@eisentraut.org обсуждение |
| Ответ на | Re: Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
| Ответы |
Re: Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter
|
| Список | pgsql-hackers |
On 15.04.26 17:07, Ashutosh Bapat wrote: > Thanks for the report. I could reproduce the segfault on my laptop. > The attached patch fixes it and gives ERROR: stack depth limit > exceeded. > > generate_queries_for_path_pattern_recurse() - has to work in a linear > fashion since the elements need to be processed in an order. Each > permutation of elements produces one query. These queries can be > arranged in a balanced tree as you suggest OR when constructing the > setop tree we could generate it in divide-and-conquer manner. However, > the tree will be flattened in the planner anyway (See > flatten_simple_union_all() and pull_up_simple_union_all()). Thus the > final planning will require a deeper stack anyway. The code complexity > doesn't seem to be worth it. > > I also looked at a few commits that add check_stack_depth() to see if > we add tests for these scenarios. But I didn't find any. So no tests > added with this commit. committed (I moved the #include "miscadmin.h" to a more alphabetical position.)
В списке pgsql-hackers по дате отправления: