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

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: zengman <zengman(at)halodbtech(dot)com>
Cc: Junwang Zhao <zhjwpku(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Subject: Re: (SQL/PGQ) cache lookup failed for label
Date: 2026-06-04 15:04:31
Message-ID: CAExHW5t422ftskE=u02rEyfuv8c3nGBf28YXfFj3-3V9+0=puA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 4, 2026 at 7:37 PM zengman <zengman(at)halodbtech(dot)com> wrote:
>
> > 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
>
> Hi Ashutosh,
>
> I applied and tested the v20260601 patches on top of master, looks good.
>
> One thing I noticed though -- RemoveRelations() in propgraphcmds.c
> cleans up orphaned pg_propgraph_property entries, but the condition
> doesn't include drop_label:
>
> ```diff
> diff --git a/src/backend/commands/propgraphcmds.c b/src/backend/commands/propgraphcmds.c
> index cc516e27020..7c8f397afbf 100644
> --- a/src/backend/commands/propgraphcmds.c
> +++ b/src/backend/commands/propgraphcmds.c
> @@ -1638,7 +1638,7 @@ AlterPropGraph(ParseState *pstate, const AlterPropGraphStmt *stmt)
> }
>
> /* Remove any orphaned pg_propgraph_property entries */
> - if (stmt->drop_properties || stmt->drop_vertex_tables || stmt->drop_edge_tables)
> + if (stmt->drop_label || stmt->drop_properties || stmt->drop_vertex_tables || stmt->drop_edge_tables)
> {
> foreach_oid(propoid, get_graph_property_ids(pgrelid))
> {
> ```
>
> ```sql
> postgres(at)zxm-VMware-Virtual-Platform:~/code/postgres$ psql
> psql (19beta1)
> Type "help" for help.
>
> postgres=# CREATE PROPERTY GRAPH g1
> VERTEX TABLES (
> v1
> LABEL vl1 PROPERTIES (a, b, c)
> LABEL vl2 PROPERTIES (a) LABEL vl3 PROPERTIES (a,b)
> );
> CREATE PROPERTY GRAPH
> postgres=# ALTER PROPERTY GRAPH g1 ALTER VERTEX TABLE v1 DROP LABEL vl1;
> ALTER PROPERTY GRAPH
> postgres=# SELECT oid, pgpname FROM pg_propgraph_property WHERE pgppgid = 'g1'::regclass ORDER BY pgpname;
> oid | pgpname
> --------+---------
> 111971 | a
> 111973 | b
> 111975 | c
> (3 rows)
> ```
>
> After dropping vl1, b and c are still there even though no label
> references them anymore. Not sure if this is worth fixing -- thoughts?

b won't be dropped since vl3 references it. But c should get dropped.
It will be interesting to see what happens if someone tries to add a
label with property c afterwards with a different data type - it will
fail, I guess. It's worth fixing for that case if nothing else.

We have gathered 3 issues in this thread, which depend upon each other
either because of code or the test queries. Can you please start a new
thread to discuss this and provide a patch fixing it?

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-06-04 15:07:48 Re: PG19beta1: GCC 16.1.1 warning: ‘actual_arg_types’ may be used uninitialized in clauses.c
Previous Message Nathan Bossart 2026-06-04 14:57:47 Re: future of PQfn()