| From: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter |
| Date: | 2026-04-11 03:57:50 |
| Message-ID: | CAHg+QDfgK0xddH8f3eAb+UVn7sBDOnv8RvM6OkP4HtHAt6aD7w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Hackers,
Two recursive functions, generate_setop_from_pathqueries() and
generate_queries_for_path_pattern_recurse() in GRAPH_TABLE rewriter are
missing check_stack_depth() calls. Consider a property graph with 400 edge
tables with a 2-hop pattern produce 160,000 path queries and therefore
160,000 recursion frames in
generate_setop_from_pathqueries(). This can easily exceed the OS stack
limit for some systems and crashes the backend.
I am proposing a stop gap fix of checking stack depth by calling
check_stack_depth for now but in future we may want to reduce the recursion
depth (for example use a balanced tree to reduce depth from O(N) to O(log
N).
Attached a patch for adding the check_stack_depth() check.
Repro:
CREATE TABLE sv (id int PRIMARY KEY);
INSERT INTO sv VALUES (1);
DO $$
BEGIN
FOR i IN 1..400 LOOP
EXECUTE format(
'CREATE TABLE se_%s (id int PRIMARY KEY, src int, dst int)', i);
END LOOP;
END$$;
DO $$
DECLARE
sql text;
edges text := '';
BEGIN
FOR i IN 1..400 LOOP
IF i > 1 THEN edges := edges || ', '; END IF;
edges := edges || format(
'se_%s KEY (id) SOURCE KEY (src) REFERENCES sv (id) '
'DESTINATION KEY (dst) REFERENCES sv (id)', i);
END LOOP;
EXECUTE 'CREATE PROPERTY GRAPH g VERTEX TABLES (sv KEY (id)) '
|| 'EDGE TABLES (' || edges || ')';
END$$;
SELECT * FROM GRAPH_TABLE(g
MATCH (a)-[e1]->(b)-[e2]->(c)
COLUMNS(a.id AS a_id))
LIMIT 1;
Thanks,
Satya
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-graph-table-check-stack-depth.patch | application/octet-stream | 1.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-04-11 04:34:14 | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |
| Previous Message | David G. Johnston | 2026-04-11 03:53:39 | Re: Possible mismatch between behaviour and documentation in CREATE FUNCTION |