Feedback-ID: ie0a040ee:Fastmail
Message-ID: <cfc37fd8-e1e7-4590-a81f-71e95b035ae0@eisentraut.org>
Date: Fri, 24 Apr 2026 08:24:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CAHg+QDfgK0xddH8f3eAb+UVn7sBDOnv8RvM6OkP4HtHAt6aD7w@mail.gmail.com>
 <CAExHW5sEQOK3F+pkZcFy=FX-dOhdittBS6A7Hf88HT841bunLg@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: 
 <CAExHW5sEQOK3F+pkZcFy=FX-dOhdittBS6A7Hf88HT841bunLg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/cfc37fd8-e1e7-4590-a81f-71e95b035ae0%40eisentraut.org>
Precedence: bulk

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.)