public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ewan Young <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: Ayush Tiwari <[email protected]>
Cc: Junwang Zhao <[email protected]>
Cc: zengman <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Subject: Re: (SQL/PGQ) cache lookup failed for label
Date: Thu, 4 Jun 2026 19:21:48 +0800
Message-ID: <CAON2xHMWgBhiBjKz2tGk0b1nQq03Fn4ESL73VUfUtVD+fuWYDQ@mail.gmail.com> (raw)
In-Reply-To: <CAExHW5sghW3VjxyQYwYaW4Q76ZEcrsCwd_AYcfPHKZFMWOHKrw@mail.gmail.com>
References: <[email protected]>
<CAExHW5v+0v8ZwDVdJF7p95cxXddLEjnQkT0RAVTPtW1NuaMO7A@mail.gmail.com>
<[email protected]>
<CAJTYsWV9uroc-1Gurh+UTbXQ2h3h-QRKYC+kHpAr9Y2GMyROBQ@mail.gmail.com>
<CAJTYsWXgD9SpR2XCkot4N5UpLCwf+_EvoRTJTEwhEm=RFEF2WQ@mail.gmail.com>
<CAEG8a3L9RTHSZ6uhyyRTB9T-hH4XZaRPCG_3zC3u-hBN0pfefQ@mail.gmail.com>
<CAJTYsWVfexEKBDfmEGZ9YCs8+Eca_zk1E7nnpjmYQvnny2WViA@mail.gmail.com>
<CAExHW5vyLHDw47+fs6Pt+CeFDN1Dhne+tHPjrJYOkkBpJ3Fhvw@mail.gmail.com>
<CAEG8a3+LEi8dN_8=K7kKo-X85SvKcy6VSPW7mXQboNwx4G+Kqw@mail.gmail.com>
<CAExHW5tyEXwxrb8-AZKx_G6fposscZRjEWs_31A06CYCC_hSLQ@mail.gmail.com>
<CAEG8a3KkZJaLNZcuEzUjJBropCpbRkYXyeoj+svaKvJVxQ9BcA@mail.gmail.com>
<CAJTYsWUufkJ8SB+S5rpbpkcpFFmR9y7xN9V8gcAMPexgJLL_6Q@mail.gmail.com>
<CAExHW5twGP5Zuk4Zch4kz8XDrSpckWQipMs=ysAj8GmqNa2FCQ@mail.gmail.com>
<CAExHW5sghW3VjxyQYwYaW4Q76ZEcrsCwd_AYcfPHKZFMWOHKrw@mail.gmail.com>
On Thu, Jun 4, 2026 at 6:45 PM Ashutosh Bapat
<[email protected]> wrote:
>
> On Fri, May 22, 2026 at 12:07 AM Ashutosh Bapat
> <[email protected]> wrote:
> >
> > On Sun, May 17, 2026 at 11:26 PM Ayush Tiwari
> > <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 18 May 2026 at 07:37, Junwang Zhao <[email protected]> wrote:
> > >>
> > >> On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
> > >> <[email protected]> wrote:
> > >>
> > >> > >>
> > >> > >> I shortened the commit message by taking essential elements from your
> > >> > >> commit message.
> > >> > >>
> > >> > >> Please review the attached patch.
> > >> > >
> > >> > >
> > >> > > The attached patch seems not for this thread.
> > >> >
> > >> > Thanks for noticing. Here's attached correct patch.
> > >>
> > >> The patch LGTM, thanks for taking care of this.
> > >
> > >
> > > +1, LGTM
> > >
> > > I've changed the status in CF entry status to Ready for Committer.
> > > https://commitfest.postgresql.org/patch/6760/
> >
> > Thanks Ayush.
> >
> > While working on this, I found two other problems. Before we dive into
> > those, I think we should commit the current patch. It need not wait
> > for a solution to these problems.
> >
> > I was checking whether we should be expanding an empty label during
> > the transformation stage instead of rewrite phase so that, in case the
> > graph pattern is part of a view definition, the set of labels the
> > empty label expression resolves to is stored in the catalogs. That
> > way, we can create a dependency of view on the set of labels at the
> > time of view. After discussing it with Peter Eisentraut, we feel that
> > doing so will be good for future-proofing pg_dump of views containing
> > graph patterns with empty labels. We will definitely need it before
> > supporting all properties reference since the properties that the all
> > properties reference expands to depends upon the set of labels in the
> > label expression. We need to create dependencies between those
> > properties and the view and hence need dependencies between labels
> > (that the empty label expression resolves to) and the view. I will
> > provide a patch for the same soon.
>
> While working on this I found another issue. An empty label expression
> may turn into no label which does not have any syntax level support.
> Hence we can't dump a view containing such an empty label expression.
> For now I have prohibited empty label expressions which do not resolve
> to any label as an unsupported feature. I doubt if there will be any
> valid use case for such a label expression.
>
> As a result a test which tests dependency between a view and the
> property graph in create_property_graph.sql failed. Failure is
> accidental as test uses an empty property graph for this purpose. I
> fixed it by adding a vertex table to the property graph being
> referenced in the view.
>
> The commit message just mentions the label dependency asymmetry
> between explicitly mentioned labels and labels resulting from empty
> label expression. I haven't gone into the details of
> all-properties-reference to keep it simple. The discussion link should
> lead a curious reader to the complex discussion here.
>
> I did reconsider whether to fix this right now or whether we can
> postpone it till we support all-properties reference. If we don't fix
> this, a query containing empty label expression will return different
> result as the set of labels in the property graph changes. When we
> will support all properties reference, we will have to fix this and
> then the behaviour will change breaking backward compatibility. So I
> think we have to fix this now.
>
> >
> > When trying different things which could lead to invalidation of view
> > if we don't add the dependency between labels (that the empty label
> > expression resolves to) and the view, I found another way to
> > invalidate the view.
> >
> > To reproduce it, run the following statements after running
> > graph_table.sql tests.
> > CREATE VIEW v_empty_label AS SELECT * FROM GRAPH_TABLE (g1 MATCH (v
> > WHERE v.vprop1 = 10) COLUMNS (v.elname));
> > BEGIN;
> > ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL l1;
> > ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v2 DROP LABEL l1;
> > ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v3 DROP LABEL l1;
> > SELECT * FROM v_empty_label;
> > ROLLBACK;
> >
> > The three ALTER TABLE statements leave the label behind since it's
> > associated with the edge tables. The SELECT statement still throws
> > "ERROR: property "elname" for element variable "v" not found". If we
> > expand the empty label reference in the transformation phase and
> > record dependencies between those labels and the view, we get a
> > different error "ERROR: no property graph element of type "vertex"
> > has label "l1" associated with it in property graph "g1"". The first
> > error is a bit obscure compared to the second one. So there's relative
> > improvement. Myself and Peter thought that the second error is an
> > artifact of the term "vertex labels" in the standard; a term which is
> > not properly defined in the standard. There are two solutions
> >
> > 1. We create vertex label and edge label as separate objects and
> > record depdencies accordingly
> > 2. We ignore the term "vertex/edge label" in the standard and handle
> > labels that exist in property graphs but have no associated element of
> > required type in the query. I think this will require some corrections
> > in standard to standardize the outcome of such queries.
> >
> > I will provide patches once we decide which approach to take.
>
> For now I have added a test case exhibiting this behaviour. If we
> commit the test, somebody who comes across this behaviour will know
> why the current behaviour is the way it is and what's the way forward.
> But if we don't commit it, which is ok, they will consider this as
> buggy behaviour and report it. I am fine either way.
>
> As I mentioned earlier, I am creating patches for all outstanding
> issues from the same branch. So the patches attached here do not start
> from 0001, but they apply with git am on the latest master for me
> without any problem.
> 0005 - fixes `cache lookup failed for label`
> 0006 - fixes empty label expression and view behaviour
> 0007 - issue with labels shared by vertex and edges
>
> --
> Best Wishes,
> Ashutosh Bapat
Hi Ashutosh,
Following up here from [1], where I was redirected to this thread,
thanks.
I don't think these are the same bug. I applied v20260601-0005
through 0007 on top of master (90354030b8f) and my test case still
fails the same way:
CREATE TABLE v1 (id int);
CREATE TABLE v2 (id int);
CREATE TABLE x (a int);
CREATE PROPERTY GRAPH g VERTEX TABLES
(v1 KEY (id) LABEL l1, v2 KEY (id) LABEL l2);
SELECT 1 FROM x, GRAPH_TABLE (g MATCH (s IS l1|l2 WHERE s.id = x.a)
COLUMNS (s.id));
ERROR: plan should not reference subplan's variable
I also tested the earlier v20260517 patches (which I understand are
what the unattached 0001-0004 of your series correspond to): same
result. That matches expectations, since everything posted in this
thread touches DDL-time code (dependency.c, propgraphcmds.c), while
this is a planner-time failure on a plain SELECT, with no views or
DDL involved.
The trigger is a lateral reference into the GRAPH_TABLE combined with
a label disjunction resolving to two different element tables. Two
labels on the same table don't trigger it, since that produces a
single path query and no UNION.
Root cause, as far as I can tell: replace_property_refs_mutator()
increments varlevelsup for lateral Vars, which is correct when the
path query becomes the subquery RTE directly. With a multi-table
label disjunction, generate_union_from_pathqueries() wraps the path
queries as subquery RTEs of a new UNION query -- one level deeper --
and nothing compensates, so varlevelsup ends up off by one.
The attached patch (same as in [1]) runs IncrementVarSublevelsUp()
over each path query in the multiple-pathquery branch of
generate_union_from_pathqueries(). It also adds a SELECT from the
existing customers_us view to graph_table.sql: that view's comment
says it exists to test exactly this lateral + disjunction
combination, but it is currently only passed to pg_get_viewdef and
never executed, which is why the regression tests don't catch this.
The patch is against master and passes make check. On top of your
v20260601 series only the test-file hunks conflict (both append to
graph_table.sql); the code hunk applies cleanly.
Given that, should this be tracked separately rather than in this
thread? Happy to go either way.
[1] https://www.postgresql.org/message-id/[email protected]...
Attachments:
[application/octet-stream] v1-0001-Fix-lateral-references-in-GRAPH_TABLE-with-label-.patch (3.7K, ../CAON2xHMWgBhiBjKz2tGk0b1nQq03Fn4ESL73VUfUtVD+fuWYDQ@mail.gmail.com/2-v1-0001-Fix-lateral-references-in-GRAPH_TABLE-with-label-.patch)
download | inline diff:
From 1c30243a8385d5ba3c977764d0d9ee493dcd8184 Mon Sep 17 00:00:00 2001
From: Ewan Young <[email protected]>
Date: Fri, 5 Jun 2026 00:07:10 +0800
Subject: [PATCH v1] Fix lateral references in GRAPH_TABLE with label
disjunction
When a graph pattern's label disjunction resolves to more than one
element table, the rewritten path queries are combined with a UNION
query, which places them one query level deeper than the GRAPH_TABLE's
own subquery level. replace_property_refs() had already adjusted the
varlevelsup of lateral references on the assumption that the path
query would itself become the GRAPH_TABLE subquery, so such references
ended up off by one, making the planner fail with
ERROR: plan should not reference subplan's variable
Compensate by incrementing the level of outer references in each path
query once more when wrapping them in a UNION query.
Also add a regression test that actually executes the customers_us
view, which was created to cover exactly this combination of lateral
references and label disjunction but was previously only exercised by
the ruleutils deparsing test.
---
src/backend/rewrite/rewriteGraphTable.c | 10 ++++++++++
src/test/regress/expected/graph_table.out | 9 +++++++++
src/test/regress/sql/graph_table.sql | 4 ++++
3 files changed, 23 insertions(+)
diff --git a/src/backend/rewrite/rewriteGraphTable.c b/src/backend/rewrite/rewriteGraphTable.c
index 33d4e866d74..3d6c85a5ea8 100644
--- a/src/backend/rewrite/rewriteGraphTable.c
+++ b/src/backend/rewrite/rewriteGraphTable.c
@@ -638,6 +638,16 @@ generate_union_from_pathqueries(List **pathqueries)
return sampleQuery;
}
+ /*
+ * Each path query will be wrapped in a subquery RTE of the UNION query
+ * constructed below, which puts it one query level further away from the
+ * query containing the GRAPH_TABLE clause than replace_property_refs()
+ * assumed when it adjusted the levels of lateral references. Compensate
+ * by incrementing varlevelsup of any outer-query references once more.
+ */
+ foreach_node(Query, pathquery, *pathqueries)
+ IncrementVarSublevelsUp((Node *) pathquery, 1, 1);
+
sostmt = castNode(SetOperationStmt,
generate_setop_from_pathqueries(*pathqueries, &rtable, NULL));
diff --git a/src/test/regress/expected/graph_table.out b/src/test/regress/expected/graph_table.out
index cc6d80afd82..924f0cff6db 100644
--- a/src/test/regress/expected/graph_table.out
+++ b/src/test/regress/expected/graph_table.out
@@ -942,6 +942,15 @@ SELECT pg_get_viewdef('customers_us'::regclass);
ORDER BY g.customer_name, g.product_name;
(1 row)
+-- exercises lateral references combined with label disjunction, where the
+-- rewritten path queries are wrapped in an extra UNION query level
+SELECT * FROM customers_us;
+ customer_name | product_name | a
+---------------+--------------+---
+ customer1 | product1 | 1
+ customer1 | product2 | 1
+(2 rows)
+
-- test view/graph nesting
CREATE VIEW customers_view AS SELECT customer_id, 'redacted' || customer_id AS name_redacted, address FROM customers;
SELECT * FROM customers;
diff --git a/src/test/regress/sql/graph_table.sql b/src/test/regress/sql/graph_table.sql
index 0e381ec72bc..f8207578d32 100644
--- a/src/test/regress/sql/graph_table.sql
+++ b/src/test/regress/sql/graph_table.sql
@@ -536,6 +536,10 @@ SELECT g.* FROM x1,
ORDER BY customer_name, product_name;
SELECT pg_get_viewdef('customers_us'::regclass);
+-- exercises lateral references combined with label disjunction, where the
+-- rewritten path queries are wrapped in an extra UNION query level
+SELECT * FROM customers_us;
+
-- test view/graph nesting
CREATE VIEW customers_view AS SELECT customer_id, 'redacted' || customer_id AS name_redacted, address FROM customers;
--
2.47.3
view thread (17+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: (SQL/PGQ) cache lookup failed for label
In-Reply-To: <CAON2xHMWgBhiBjKz2tGk0b1nQq03Fn4ESL73VUfUtVD+fuWYDQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox