Repository navigation
Variable-length path fan-out followed by DETACH DELETE fails with an internal missing-vertex error #2539
Description
Docker image apache/age:release_PG18_1.7.0.
Reproduction
LOAD 'age';
SET search_path = ag_catalog, public;
SELECT ag_catalog.create_graph('age_issue_case13');
SELECT *
FROM ag_catalog.cypher('age_issue_case13', $$
CREATE (c {id: 1001})-[:rt13]->(a {id: 1002})
$$) AS (v agtype);
SELECT *
FROM ag_catalog.cypher('age_issue_case13', $$
MATCH (c {id: 1001})
CREATE (c)-[:rt13]->(b {id: 1003})
$$) AS (v agtype);
SELECT *
FROM ag_catalog.cypher('age_issue_case13', $$
UNWIND [1] AS i
MATCH p = ()-[:rt13*..6]-(n)
DETACH DELETE n
RETURN i
$$) AS (i agtype);Expected
The query completes and returns the scalar i for each matched path row.
Deleting the matched vertices must not make the scalar-only RETURN fail.
Actual
Apache AGE 1.7.0 reports an internal executor error instead of returning
the rows:
ERROR: add_valid_vertex_edges: no vertex found
Activity
gregfelice commentedon Aug 21, 2026
I could not reproduce this on current master (
4d9b2506, AGE 1.8.0, PostgreSQL 18.4). Running your reproducer verbatim, the final query returns the six rows you describe as expected, with no missing-vertex error:Your report is against the
apache/age:release_PG18_1.7.0Docker image, so this looks fixed between 1.7.0 and 1.8.0 — though I want to be careful about naming a commit. I checked whether #2495 was responsible by rebuilding at5f324f82, the commit immediately before it; the reproducer already passed there, so that is not the fix and I did not bisect further.Could you retest on 1.8.0 / master? If it still reproduces for you, the difference is environmental and worth chasing rather than closing.
YGY-001 commentedon Aug 21, 2026
You're right; it works fine in version 1.8.