Re: (SQL/PGQ) cache lookup failed for label

On Thu, Jun 4, 2026 at 6:45 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Fri, May 22, 2026 at 12:07 AM Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> >
> > On Sun, May 17, 2026 at 11:26 PM Ayush Tiwari
> > <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 18 May 2026 at 07:37, Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
> > >>
> > >> On Mon, May 18, 2026 at 8:22 AM Ashutosh Bapat
> > >> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> 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/CAON2xHOYJ+dGZznY+oPyBHdLfRtzThQid5iEc-HOxODs3pb3AA@mail.gmail.com