| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter |
| Date: | 2026-04-24 06:24:13 |
| Message-ID: | cfc37fd8-e1e7-4590-a81f-71e95b035ae0@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-04-24 06:26:03 | pgbench: make verbose error messages thread-safe |
| Previous Message | Bertrand Drouvot | 2026-04-24 06:21:25 | Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE |