Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter - Mailing list pgsql-hackers

From SATYANARAYANA NARLAPURAM
Subject Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter
Date
Msg-id CAHg+QDfgK0xddH8f3eAb+UVn7sBDOnv8RvM6OkP4HtHAt6aD7w@mail.gmail.com
Whole thread
Responses Re: Bug: Missing check_stack_depth() in GRAPH_TABLE rewriter
List 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

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Possible mismatch between behaviour and documentation in CREATE FUNCTION
Next
From: Amit Kapila
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication