MatheusFarias03 opened a new issue, #1055: URL: https://github.com/apache/age/issues/1055
Me and other Bitnine interns are in a project to upgrade AGE to Postgres version 16. One of the main problems that we are facing is that the code was [reworked to update the permission checking](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a61b1f74823;hp=b5bbaf08ed8bbc45d396c3383fc89331c914b857) and now some of the queries return `ERROR: invalid perminfoindex <rte->perminfoindex> in RTE with relid <rte->relid>`. This occurs due to one of the RTEs having `perminfoindex = 0` and the relid containing a value. When we do a simple `MATCH` query to find all nodes with the v label: ```sql SELECT * FROM cypher('cypher_set', $$ MATCH (n:v) RETURN n $$) AS (node agtype); ``` inside the `add_rtes_to_flat_rtable()` function, it goes inside a loop where we can see the stored RTEs in `root->parse->rtable`: ```c // I've simplified what every RTE shows. root->parse->rtable [ (rtekind = RTE_SUBQUERY, relid = 0, perminfoindex = 0), (rtekind = RTE_SUBQUERY, relid = 0, perminfoindex = 0), (rtekind = RTE_SUBQUERY, relid = 0, perminfoindex = 0), (rtekind = RTE_RELATION, relid = 16991, perminfoindex = 1) ] ``` But executing the query with a simple `SET` clause: ```sql SELECT * FROM cypher('cypher_set', $$ MATCH (n) SET n.i = 3 $$) AS (a agtype); ``` One of the RTEs of the `RTE_RELATION` type and `relid` with a not null value has `perminfoindex = 0` ```c root->parse->rtable [ (rtekind = RTE_SUBQUERY, relid = 0, perminfoindex = 0), (rtekind = RTE_RELATION, relid = 16971, perminfoindex = 1), (rtekind = RTE_RELATION, relid = 16971, perminfoindex = 1), (rtekind = RTE_RELATION, relid = 16991, perminfoindex = 0) ] ``` The `relid = 16991` is related to the child vertex label and the `relid = 16971` related to the parent vertex label: ```sql SELECT to_regclass('cypher_set._ag_label_vertex')::oid; to_regclass ------------- 16971 SELECT to_regclass('cypher_set.v')::oid; to_regclass ------------- 16991 ``` Here is the back-trace of when the error occurs: ```txt 3905 elog(ERROR, "invalid perminfoindex %u in RTE with relid %u", (gdb) bt #0 getRTEPermissionInfo (rteperminfos=0x138a500, rte=0x138a6b0) at parse_relation.c:3905 #1 0x0000000000676e29 in GetResultRTEPermissionInfo (relinfo=relinfo@entry=0x13b8f50, estate=estate@entry=0x138ce48) at execUtils.c:1412 #2 0x0000000000677c30 in ExecGetUpdatedCols (relinfo=relinfo@entry=0x13b8f50, estate=estate@entry=0x138ce48) at execUtils.c:1321 #3 0x0000000000677cd7 in ExecGetAllUpdatedCols (relinfo=relinfo@entry=0x13b8f50, estate=estate@entry=0x138ce48) at execUtils.c:1362 #4 0x000000000066b9bf in ExecUpdateLockMode (estate=estate@entry=0x138ce48, relinfo=relinfo@entry=0x13b8f50) at execMain.c:2385 #5 0x00007f197fb19a8d in update_entity_tuple (resultRelInfo=<optimized out>, resultRelInfo@entry=0x13b8f50, elemTupleSlot=elemTupleSlot@entry=0x13b9730, estate=estate@entry=0x138ce48, old_tuple=0x13bae80) at src/backend/executor/cypher_set.c:120 #6 0x00007f197fb1a2ff in process_update_list (node=node@entry=0x138d0c8) at src/backend/executor/cypher_set.c:595 #7 0x00007f197fb1a348 in process_all_tuples (node=node@entry=0x138d0c8) at src/backend/executor/cypher_set.c:212 #8 0x00007f197fb1a455 in exec_cypher_set (node=0x138d0c8) at src/backend/executor/cypher_set.c:641 ``` I have sent a few emails to `pgsql-hackers` about this, with the [first email](https://www.postgresql.org/message-id/CANQ0oxfxBKKTReQgSh_KbL99DqdjfBZTastC0XT2ZZMBkAhTQw%40mail.gmail.com) stating this issue. I have received help from Tom Lane and Amit Langote, both pointed out that the result-relation RTE has no permissions info associated and that, when the `p_rtable` member of `cpstate->pstate` has any `RTE_RELATION` entries whilst `p_rteperminfos` being `NIL`, it is a bug (but from what I've checked, in the SET query it has a `RTE_SUBQUERY`). Furthermore, Amit wrote in his latest response that he was suspecting more of a problem in the code that generates a `ResultRelInfo` pointing at the wrong RTE via its `ri_RangeTableIndex`. That code should perhaps set the `ri_RangeTableIndex` to 0 if it doesn't know the actual existing RTE corresponding to that result relation. If we set it to some non-0 value, the RTE that it points to should satisfy invariants such as having the corresponding `RTEPermissionInfo`present in the `rteperminfos` list if necessary. I've seen that there are some functions in AGE's code that deal with the `ResultRelInfo` struct, such as: `transform_merge_cypher_node()`, `transform_merge_cypher_edge()`, `transform_create_cypher_new_node()`, `transform_create_cypher_existing_node()`, and `transform_create_cypher_edge()`. However, when executing the `SET` query it doesn't trigger any of these functions that deal with `ResultRelInfo`. If anyone with more experience with AGE's source code knows where this is done and how to change the `ResultRelInfo` in this case, I would be deeply grateful for any kind of help or advice. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@age.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
